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Figure 1 
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Figure 2 
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METHOD AND APPARATUS FOR 
MANAGING DATA EXCHANGE AMONG 
SYSTEMS IN A NETWORK 

This application claims the benefit of U.S. Provisional 
Application No. 60/176,137, filed Jan. 14, 2000. This appli- 
cation is also related to the following utility applications 
which are filed on the same day as this application: 

Ser. No. 09/760,068, filed Jan. 12, 2001, entitled "Method 
And Apparatus For A Business Applications Manage- 
ment System Platform;" 

Ser. No. 09/759,491, filed Jan. 12, 2001, entitled "Method 
and Apparatus for a Business Server;" 

Ser. No. 09/759,856, filed Jan. 12, 2001, entitled "Method 
and Apparatus for a Web Content Platform;" 

Ser. No. 09/760,432, filed Jan. 12, 2001, entitled "Method 

■ and Apparatus for an information Server;" ■ — 

Ser. No. 09/759,062, filed Jan. 12, 2001, entitled "A 
Method and Apparatus for an Improved Security Sys- 
tem Mechanism in a Business Applications Manage- 
ment System Platform." 

COPYRIGHT NOTICE 

A portion of this patent document contains material which 
is subject to copyright protection. The copyright owner has 
no objection to the facsimile reproduction by anyone of the 
patent document or the patent disclosure, as it appears in the 
Patent and Trademark Office patent file or records, but 
otherwise reserves all copyright rights whatsoever. 

TECHNICAL FIELD 

The present invention relates to the general field of 
computers, telecommunications, and computer and Internet 
related systems. More specifically the invention relates to 
systems and processes to be used in a business systems 
platform generally used to integrate disparate business appli- 
cations systems in an efficient manner, across multiple 
hardware platforms. 

BACKGROUND 

The Internet and other communications networks provide 
a mechanism for communication and transfer of data 
between a wide variety of systems and platforms. There is a 
need for a system for managing the exchange of data and 
information among applications which may be housed on 
disparate hardware platforms and in diverse locations. 
Moreover, there is a need for a system that provides stan- 
dardized access to connectivity with other systems and 
platforms in a users network. 

Prior art systems of this type typically have an infrastruc- 
ture which is tightly coupled to application products, spe- 
cific hardware platforms and specific Operating systems and 
related services. Such systems are difficult to maintain, 
difficult to upgrade and difficult to extend to other applica- 
tions as well as usually requiring redundant data input for 
their specific applications. In the past, developers have 
turned to object-oriented programming (OOP) to improve 
programming and code maintenance efficiency for such 
systems and to the use of hardware platform independent 
languages like Sun Microsystems™ JAVA™ language and 
system, as tools for developing such platform independent 
applications support systems. Until recently, the use of Java 
has been focused on the client side of the client-server 
system architecture with the development of JavaBeans™ 
and Java servelet generation. More recently, the technology 
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required to allow distributed objects to communicate with 
each other across either the client-server or server-server 
boundary has been provided by the EnterpriseJavaBeans 
(EJB)™ component architecture. This new architectural 
5 system and related tools and systems are well documented 
and well known to those skilled in these arts. 

Attempts continue to be made to employ these new 
systems and architectures in the process of building generic 
applications systems platforms, in an attempt to make the 

10 applications platform independent of a given hardware and 
software platform, and to make them easier to use by 
developers and end-users. For example, U.S. Pat. No. 6,125, 
363 issued on Sep. 26, 2000 to Eugene Buzzeo et al provides 
an object-oriented, multi-threaded application development 

!5 system and method for developing resource information 
software, wherein a three tier framework (web client and 
web browser — web server — application server) is disclosed. 
The system disclosed uses JAVA objects as connectors; 
components, agents, event servers, common objects with 

20 which to build applications for database related applications 
which are hardware platform independent ITie system 
described in this Patent tries to solve the problems of 
distributed object communications through the use of the 
Common Object Request Broker Architecture (CORBA) 

25 and the InternetlnterORB Protocol (IIOP). Such platform 
independent languages, tools and sub-systems, while osten- 
sibly making it easy for applications developers to create 
new business applications, nevertheless present an over- 
whelming technical problem for a user with a need for an 

30 efficient, integrated business system. A system using one 
framework is unable to transfer data to a different 
framework, as systems implementing one framework will 
have a different application programming interface API than 
the application programming interface API of another sys- 

35 tern. 

Accordingly, there is a need in the art for a modular 
interconnect system containing data import, export and 
event monitoring and reporting facilities which are protocol 
independent of related applications. There is a need for an 

40 interconnect system which implements a generic connector 
framework with pluggable system specific components uti- 
lizing native application programming interfaces of systems 
to manage export and import of data from external systems. 
There is also a need for such an interconnect system utilizing 

45 XML, and there is a need for reliable monitoring mecha- 
nisms for changes to data in external systems. The current 
invention provides these facilities and others in various new 
and novel ways as more fully described below. 

50 SUMMARY OF THE INVENTION 

The present invention presents a method for managing 
data exchange among systems connected via a network A 
plurality of predefined stylesheets are generated, with each 
stylesheet describing a mapping between a system specific 

55 local format and a generic interchange format. A data object 
is received from a first system in a first system specific local 
format. This data object is translated from the first system 
specific local format to a generic interchange format object 
with the predefined stylesheets using a system specific 

60 service component which utilizes a native application pro- 
gramming interface of said first system. The data object is 
then translated from the generic interchange format to a 
second system specific local format object with the pre- 
defined stylesheets using a system specific service compo- 

65 nent which utilizes a native application programming inter- 
face of said second system. The translated data object is then 
transferred to the second system. 
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In one embodiment of the invention, the step of receiving FIG. 5 illustrates an alternative configuration of the sys- 

a data object from a first system in a first system specific tem which contains the invention. 

local format includes receiving a request to export a data mG 6 ^ an alternative depiction of the platform of the 

object from a first system, identifying a local data object pres ent invention 

identifier utilizing a mapper component, identifying a docu- < Mjr , „ .„ „ 

ment type utilizing a mapper component, identifying a FIG * 7 illustrates * more detailed configuration of an 

stylesheet and transformer using said document type, and exemplary business server portion of the current invention, 

extracting the data object from the first system. FIG. 8A illustrates a more detailed configuratioD of an 

The present invention presents a system for managing exemplary Web Content Server portion of the current inven- 

data exchange among a plurality of systems connected via a 1Q tion. 

network. The system comprises a network interface, FIG. 8B shows a process flow diagram illustrating how to 

memory storing data and programs of instructions, and a produce dynamic web content 

processor coupled to the memory which executes the pro- FIG. 8C shows a process flow diagram illustrating the 

grams of instrucUons and accesses the stored data. The development process 

programs of instructions comprise a first component for 1( - n M , r , , , , 
translating a data object from a first system specific local 15 mG ' V*^*™ * P embodiment of the Inter- 
format to a generic interchange format object, a second connect Backbone. 

component for translating the data object from the generic . .. . 1.0 shows a process flow diagram aiustrating a_ 

interchange format to a second system specific local format purchase order delivered from a Source site to a target 

object, and a third component for transferring the data object 2Q system through Interconnect. 

between the first and second system. The first component FIG. 11 illustrates one embodiment of the structural 

further comprises a system independent service subcompo- overview of an IDK. 

nent and a system specific service subcomponent utilizing a n illustrates one embodiment of a functional over- 
native API of said first system to translate said data object to vicw of m information Distributor. 

a generic interchange format object using a predefined oi: ™„ „ .„ t 4 t . c . , 

A , , rj., 0 , . ° . 25 FIG. 13 illustrates an exemplary view of APIs associated 

stylesheet. The second component further comprises a sys- me Information JXstxSb ^ y 
tem independent service subcomponent and a system spe- 

cific service subcomponent utilizing a native API of said first mG : 14 t illustrates an exemplary view of using Informa- 

system to translate said data object from a generic inter- tion Distributor or IDK. 

change format object to a second system specific local 3Q FIG. 15 illustrates an exemplary overview of Query 

format object using a predefined stylesheet. Objects. 

The system may also include a monitor component for FIG. 16 illustrates an exemplary overview of the Imple- 

monitoring changes of a data object at a system, with the m ent Custom Delivery Service 

monitoring component having both a system independent nG n a ^ embodiment of the Busi- 

semce subcomponent and a system specific service com- 35 ness ApplicatioQS Management System Platform, 
ponent utilizing a native API of the monitored system to 

monitor changes of the data object. The system may also DETAILED DESCRIPTION 
include a mapper component for identifying a local object 

identifier and a document type. The present invention provides a solution to the needs 

Still other embodiments of the present invention will 40 described above through a system and method for integrat- 

become apparent to those skilled in the art from the follow- ing the disparate applications, and managing the applica- 

ing detailed description, wherein is shown, and described tions processes in a hardware resource and user effort 

only the embodiments of the invention by way of illustration efficient manner. The automated system of the present 

of the best modes contemplated for carrying out the inven- invention uses a business systems platform architecture 

tion. As will be realized, the invention is capable of modi- 45 comprised of several unique servers in a base platform (the 

fication in various obvious aspects, all without departing "Platform") to efficiently manage multiple applications 

from the spirit and scope of the present invention. which may themselves generally be distributed across a 

Accordingly, the drawings and detailed description are to be network. The platform makes use of a collection of Core 

regarded as illustrative in nature and not restrictive. Services which provide additional security, internationaliza- 

DESCRIPTION OF THE DRAWINGS » «ryiocs. and reporting services which are applicable to 

all applications. The Core Services are made available to a 

The features and advantages of the system and method of multitude of common business objects, which themselves 

the present invention will be apparent from the following are made available to various applications, 

description in which: The present invention is a Business Applications Man- 

FIG. 1 illustrates a typical configuration of Internet cod- 55 agement System piatfomj Architecture (the -platform" or 

nected systems representative of the preferred embodiment alternatively the "SABA architecture") which is designed to 

of the present invention. maintain and use a set of unique servers and common objects 

FIG. 2 illustrates a typical general purpose computer to gyrate the set of tasks required to be performed to 

system of the type representative of the preferred embodi- complete a designated business transaction in a concrete, 

mcnt - 60 and useful way. In the preferred embodiment, the platform 

FIG. 3 illustrates the general three tier relationship permits application developers to work on the business 
between user, web-servers and their related applications- aspects of the application without having to focus on trans- 
server, and the database management system. action management, security, persistence of data or life cycle 

FIG. 4 illustrates a more detailed depiction of the management of the object itself. The servers and other 

applications-server portion of such a system as shown in 65 aspects of the Platform are described in more detail below. 

FIG. 3 illustrating the business applications platform system However, a general overview of a preferred embodiment of 

of the present invention. the invention is first described. 
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(1) General Overview 

The technology used as part of the system currently is, 
and will be, able to interface with many other industry 
standard software programs to make the exchange and flow 
of data easy and accurate. 5 

The system is predominantly web-enabled, which extends 
its use to all industry professionals connected to the Internet. 
The Platform provides a unified set of interfaces, an appli- 
cation Framework, that encompass Business Object 
development, Web-application development, external con- 10 
nectivity development, and information distribution devel- 
opment. 

The system is predominantly based on object-oriented 
programming principles is described in "Object-Oriented 
Software Construction" by Bertrand Meyer, Prentiss-Hall, 15 
1988, ISBN 0-13-629049-3 and the Sun Microsystems™ 
_ developed JAVA™ systems described in the following pub- 
lications: 

Enterprise JavaBeans Specification, v 1 . 1 (can be found at 2Q 

//java^un.com/products/ejb/docs.html) 
Enterprise JavaBeans, Richard Monson-Haefel, O'Reilly. 
Enterprise JavaBeans: Developing Component-Based 

Distributed Applications, Tom Valesky, Addison - 

Wesley. 25 
Enterprise JavaBeans Developer's Guide (Beta ^rsion) 

at 

//developer.java.sun.com/developer/earlyAccess/j2sdkee/ 

d^-beta/g^des/ejb/html/rOC.html 
J2EE Application Programming Model (Beta Release), at 30 

//developerjava. sun.com/developer/earlyAccess/ 

j2sdkee/download-docs.html 

all of which are incorporated fully herein by reference. 
The system makes use of some third party modules 
which are described in more detail below also. The 35 
terminology as used and described in these refer- 
ences for object, class, inheritance, component, 
container, bean, JavaBean, EJB, etc., are well known 
in these arts and are used herein generally without 
definition except where a specific meaning is 40 
assigned to a term herein. 
Overview of the Platform Architecture 
The following describes an overview of the preferred 
embodiment of the SABA architecture, and includes: 
A discussion of the system-level architecture and the 45 
modules that comprise the SABA system. This includes 
a high-level overview of each module, and lists the 
principle interfaces and functionality defined by each 
module. 

A discussion of the application-level architecture, cover- 
ing both the application-level architecture as exposed to 
different categories of users and some of the core 
business objects and their relationships. 

Referring now to FIG. 5, in the preferred embodiment, 5S 
Saba's architecture consists of four layers of APIs: 

1. The Platform layer 501 provides underlying infrastruc- 
ture for enterprise applications, including standards- 
based functionality for persistence and distributed 
logic, application integration, content generation, and go 
metadata queries. 

2. The Core Services layer 503 is a module that provides 
a set of common functionality for enterprise applica- 
tion. It includes services such as security, 
internationalization, and reporting. 65 

3. The Common Business Objects layer 505 is a module 
that defines a set of business objects shared across all 
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SABA applications. It includes objects such as Party 
and Plan. Vertical applications may each also contrib- 
ute a set of common business objects. 
4. The Applications layer 507 provides objects and ser- 
vices particular to a given application. There are mul- 
tiple modules contained within the Applications layer, 
including modules for Learning 525, Content 527, 
Performance 529, and Sales & Marketing 531. The 
specific applications modules indicated are shown by 
way of example. 
In the preferred embodiment, applicants have standard- 
ized their APIs around Session Bean Managers, interfaces 
that expose a common set of functionality. Each module 
therefore consists of several Session Bean interfaces. Thus, 
while SABA implements its managers using Entity Beans 
corresponding to persistent database objects, the interface as 
exposed to clients is solely that of the Managers. 

This architecture^also* helps* avoid circular'dependejicies ' 
by requiring that all dependencies be directed downwards. 
That is, a vertical application 507 may have dependencies on 
one or more sets of common business objects 505, but not 
on other applications. Similarly, common business objects 
505 may depend on core services 503, and on other common 
business objects 505, but not on applications 507. 
Platform 

The Platform model 501 defines applicants' application 
platform, on top of which all additional business logic and 
functionality are implemented. Platform 501 provides the 
full set of standards-based services required for building 
modem enterprise applications. 

Platform 501 consists of the following services: 
BDK (Business Development Kit) Business applications 
server 519 is Saba's EJB compatibility layer. It extends 
the standard Java business component model with 
SABA-specific enhancements, such as improved secu- 
rity and caching, as well as providing an abstraction 
layer to improve portability between EJB servers. The 
BDK 519 defines the following base interfaces: 
ISabaEntityBean — The abstraction of a persistent 
object 

ISabaSessionBean — The abstraction of a transactional 
service 

WDK (Web Development Kit) server 523 is Saba's web 
content generation engine. Using web standards for 
XML and XSL, it provides a customizable framework 
for decoupling data from presentation, and generating 
web content in a variety of formats, from standard 
HTML to WML. The WDK 523 provides the following 
base interfaces: 

IWDKObject — An object capable of serializing itself 
as XML 

Interconnect is Saba's application integration platform. 
Using XML and open standards for ERP integration, it 
provides a scalable and reliable solution for batch and 
period import, export, and monitoring. Interconnect 
defines the following base interfaces: 
IAccessor — Service for exporting objects from SABA 
Ilmporter — Service for importing objects into SABA 
IMonitor — Service for monitoring object changes 

Information Distributor Server 521 is applicants' query 
and delivery mechanism. Based on XML and RDF 
metadata standards, it defines a high-level query lan- 
guage and a set of agents for implementing information 
services. Interconnect provides the following services: 
MetadataRepository — A datastore for querying meta- 
data 
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ImportAgent — An agent for generating metadata 
MatchAgent — An agent for locating metadata-based 
matches 

Delivery Agent — An agent for delivering match results 
Core Services 503 5 
The Core Services module 503 provides the common 
business services needed by applicants' system. These ser- 
vices are not specific to any industry, such as learning; 
instead, they provide the support and functionality required 
by applicants to meet generic enterprise requirements. 
Core Services consist of the following Session Managers: 
AuditManager — Tracks changes to objects in the system. 
Can return a complete history of changes, including 
date, useroame, and reason. 15 
BusinessRuleM anager — Manage system business rules, 
that is, company policies defining the system's behav- 
ior in given situations. 
ComponentManager — Manage installed business objects 

for naming and instantiation. 
CurrencyManager — Manage currencies and exchange 
rates. 

DataDictionaryManager — Manage metadata about busi- 
ness objects. This metadata is used to generate user 25 
interfaces, specify constraints, and define object behav- 
ior. 

DomainManager — Manage domains. Domains are hier- 
archical groupings of business objects that can be used 
for a variety of purposes. 30 

FinderManager — Create and invoke Finders. Finders pro- 
vide a flexible mechanism for defining and executing 
database queries. 

HandleManager — Centralize access to managers avail- 35 
able to all business objects. 

il8nManager — Manage internationalization. Track infor- 
mation about locales, languages, timezones, and dis- 
play formats associated with business objects. 

LicenseManager — Manage software licensing. Track 40 
installed modules, license keys, and version numbers. 

LOVM anager — Define lists of values. 

NLevelHierarchyManager — Support for nested folders. 
FolderManager 
FolderHementM anager 

NoteManager — Define notes (long text attachments). 

PreferenceManager — Set user preferences. 

SecurityManager — Manage user privileges. Assign per- 
mitted operations on objects to users and groups. 50 

ServiceHolderManager — Enable and disable common 
services (discussion, chat, etc.) 

ReportM anager — Create and execute reports. Reporting 
engines currently supported include Brio and Crystal 
Reports 7. 55 
LetterM anager — Generate form letters. 

TaxManager — Calculate sales taxes. 

NotificationManager — Manage notifications. Associate 
actions, such as sending an email or executing a Java 60 
method, with predefined system and periodic events. 

ActionM anager 

AttachmentManager 
EventManager 

ParamManager 65 

RecepientManager 

TextBlockM anager 



45 



UserManager — Manage user preferences and allow used 

to switch between roles. 
Common Business Objects 

The Common Business Objects module 505 defines the 
set of business abstractions that are shared across more than 
one vertical application. These objects may be either generic 
business concepts, such as a Party, or shared concepts 
specific to Saba's application domain, such as Calendar. 

Common Business Objects 505 comprise the following 
Session Managers: 

AccountabilityManager — Used to manage a variety of 
relationships, such as reporting and organization 
membership, between entities in the system 
CalendarM anager — Manage calendars and schedules. 
CorporateCalendarM anager 
PersonalCalendarManager 
SfaCalendarManager 
SfaCalendarOwnerManager 
CheckListltemManager 
PartyManager — Manage entities within a business. 
Includes employees, clients, companies, departments, 
and business units. 
LocationManager — Manage locations, including 

addresses and contact information. 
RoleManager — Manage a function/job type within the 
value chain. 

PlanManager — Manage plans, that is, proposed course of 
actions. 

ProfileManager — Manage profiles, that is, comprehensive 
histories, goals, and plans for entities within a business. 

ValueChainManager — Manage value chain relationships 
between entities in an extended organization. 

Learning 

The exemplary Learning module 525 within the Applica- 
tions layer 507 defines the services used to build learning 
management systems. It provides APIs for defining learning 
offerings, which include classes, courses, on-line learning, 
and physical inventory, registering for and consuming 
learning, and tracking transcripts, certifications, and other 
results of learning. 

The following Learning Session Managers are delivered 
as part of Common Business Objects 505: 
CatalogManager — Browse a learning catalog. 
OfferingTemplateManager — The core abstraction of a 

learning intervention. 
The following Learning Session Managers are only avail- 
able with the Learning application: 

CertificationM anager — Track certifications. 
CertificationActionManager 
CertificationCompetencyManager 
HeldCertificationManager 
LearningM anager — Manage learning offerings. Extends 
the concept of offering templates to include managing 
delivery types and delivery modes, offering instances, 
audience types, and offering modes. 
AudienceTypeManager 
DeliveryManager 
DeliveryModeManager 

EquivalentManager — Defines equivalent offering tem- 
plates. 
OfferingActionManager 
OfferingManager 
OfferingPolicyManager 
OfferingTemplateDeliveryManager 
ProductGroupManager 
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RosterManager 

PrerequisiteManager 
LearningResourceManager — Manage resources used by 

classes, such as classrooms, faculty, and equipment. 

InventoryManager 5 

QualifiedlnstructorManager 
RegistrarManager — Request and order a learning 

resource. Includes shipping and registration informa- 
tion. 

CourseRequestManager 10 

PackageOrderManager 

PricingManager 
RegistrationManager — Track completion and grading of 

learning offerings 
Content 

The Content module 527 within the Applications layer 
507 defines the. services, used for all forms on ..on-line 
learning. It includes creating and launching WBT and VOD 
courseware, virtual classrooms, testing and assessment, 2Q 
community services, and analysis and tracking. 

The following Content Session Manager is delivered as 
part of Common Business Objects: 

ContentHolderManager — Allows any business object to 

be a content holder 25 
CourseContentManager — Associate content such as 

attachments and exams with learning offerings. 
The following Content Session Managers are only avail- 
able with the Content application: 

ContentManager — Manage learning content. 30 

TestManager 
AnalysisManager — Analyze test results. 
CommunityManager — Create and manage learning com- 
munities. 

Performance 35 
The Performance module 529 within the Applications 
layer 507 defines the services available for managing human 
performance. It includes competencies and goals. 

The following Performance Session Managers are deliv- 
ered as part of Common Business Objects: 

CompetencyManager — Assign competencies to roles, 
entities, and learning resources. Includes 
CompetencyHolderManager 

CompetencyProviderManager ^ 
OfferingCompetencyManager — Associate competencies 

with offering templates and find learning interventions 

that provide competencies. 
The following Performance Session Managers are only 
available with the Performance application: 50 
Advanced competency definition, manipulation, and 

analysis, including: 

Competency AnalysisManager 

CompetencyGroupManager 

CompetencyMethodManager 55 
CompetencyModelManager 
GoalManager — Manage and track goals. Includes assign- 
ing goals and observations on goals. 
GoalLibraryManager 

GoalObservationManager 60 
GoalStateManager 
Sales and Marketing 

The Sales and Marketing module 531 within the Appli- 
cations layer 507 defines the services available for the 
running the finances and logistics of a learning content 65 
provider. It includes the purchase of learning resources and 
tools for managing sales and marketing campaigns. 



40 



The following Sales and Marketing Session Managers are 
delivered as part of Common Business Objects: 

OrderManager — Generate orders. Includes invoicing and 
shipping options. 

PurchaseManager — Track the pricing of learning 
resources. Includes getting and setting prices and man- 
aging price lists. 

The following Sales and Marketing Session Managers are 
only available with the Sales and Marketing application: 

AccountManager — Manage client accounts. 

Advanced order management, including: 
TrainingUnitManager 
PurchaseOrderManager 

MarketingManager — Manage marketing campaigns. 
RoyaltylnfoManager 
ShipperManager 

SalesMktManager — Order a learning resource.. Similar, 
functionality to RegistrarManager, but designed for use 
in a call center to fulfill external orders. 

TargetMarketManager — Manage target markets and asso- 
ciate them with offering templates. 

TerritoryManager — Manage territories. 

Applications Architecture 

An exemplary version of an application architecture 
which can make use of applicants* invention could consist of 
four distinct applications that interoperate to provide a 
complete Human Capital Development and Management 
solution. Each of these applications is based around a core 
set of metadata; the applicants' architecture's value lies in 
the effective management of this metadata. The diagram in 
FIG. 6 describes this core metadata and how it is employed 
by different types of users in this exemplary implementation 
of this architecture. Those skilled in the art will recognize 
that this architecture can be used with various other kinds of 
applications systems, such as: financial product sales & 
marketing systems; retail store management systems; vari- 
ous kinds of maintenance & repair management & dispatch 
systems; etc. 

Referring now to FIG. 6, SABA Learning manages Cata- 
log Metadata 609 that describes a set of available learning 
interventions and Profile Metadata 611 that describes a 
learner in the system, including learning history and enroll- 
ments. 

SABA Performance manages Profile Metadata 611 that 
describes individual and group goals, competencies, and 
development plans. Together, the Profile Metadata 611 in 
Learning 607 and Performance 605 provide a complete 
description of the human capital in an extended organiza- 
tion. 

SABA Information 603 and SABA Content 601 manage 
metadata about a variety of on-line resources. SABA Infor- 
mation 603 uses this metadata to construct information 
services targeted to individual's information needs, whereas 
SABA Content 601 uses this metadata to manage learning 
content throughout its lifecycle and construct intelligent, 
reusable Learning Objects. 

Users work with this metadata as follows: 
Individual learners 619 query Learning Metadata (that is, 
the learning catalog) 609 to locate appropriate learning 
interventions. The system uses Learning Object Meta- 
data 613 to deliver and track learning interventions and 
updates the Profile Metadata 611 as appropriate. 
Team managers 621 work with Profile Metadata 611 to 
define, update, and track progress towards goals. They 
can analyze the metadata to identify problem areas and 
generate plans for meeting their goals. 
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Learning providers 617 use import and administration contains mechanisms to manipulate various kinds of display 

tools to create and update Catalog 609 and Learning style sheets, to generate and execute web links, to manage 

Object Metadata 613. dynamic content generation and dynamic generation of 

One of the principal tasks users perform in such a system Javascript, all of which is described in more detail below in 

is finding performance interventions-resources and ser- 5 the section on the Interface Server/WDK 417. 

vices that can be applied to improve human capital perfor- These servers and related facilities and others are 

mance. The diagram in FIG. 7 details the business objects described in more detail below, 
that support this process and their relationships. 

There are multiple, complementary mechanisms for iden- ^_ . „ . 

tirying interventions. 10 OperaUng Environment 

Competency gap analysis can be applied to either an The environment in which the present invention is used 

individual s goals 713 or roles 715. The analysis compares encompasses the use of general purpose computers as client 

the requyed competencies for reaching a goal 713 or filling or input machines for use by business users of various kinds, 

a role 715 (either held or targeted) to actual held compe- including clerks, managers, teachers, and/or systems admin- 

tencies and generates a competency gap 721. Learning 15 istrators. Such client or input machines may be coupled to 

mtervennons (offerings 723) that fill the competency gap the Internet (sometimes referred to as the "Web") through 

721 are the identified. A variety of other intervention types telecommunications channels which may include wireless 

" are planned/ including information 733 and community -devices and systems i as well. - - — 

services 735. 

Certification gap 719 analysis compares a role's certifi- 20 Some ° f ^ elements of a typical Internet network 

cation requirements associated to the actual learning profile -configuration arc shown in FIG. 1, wherein a number of 

of the individual in the role. It then identifies the quickest cHent machines 105 possibly in a branch office of a large 

certification track to completion and recommends appropri- enterprise, a manufacturer, a financial enterprise, etc., are 

ate learning offerings 723 from the catalog. shown connected to a Gateway/hub/tunnel-server/etc. 106 

Having described an exemplary application we now 25 ™ hich fe itself connected to the internet 107 via some 

describe the invention in additional context. internet service provider (ISP) connection 108. Also shown 

In a preferred embodiment, the Platform can support both are ? ther P 0 ^ 1 * clients 101 > 103 possibly used by other 

Application and Business component development, as well application systems users, or interested parties, similarly 

as integration with development tools, connectivity to exter- connected to the internet 107 via an ISP connection 104, 

nal systems (import/export/exchange), and information 30 wth these um^ communicating to possibly a home ofBce via 

delivery. The architecture of the present invention adopts a an ISP connection 109 to a gateway/tunnel-server 110 which 

three-tier model and is shown in the diagram in FIG. 3. In K connected 111 to various enterprise application servers 

FIG. 3 a tier 1 web user 301 is connected electronically to ^ 114 which could be connected through another 

a tier 2 web server 305 which is connected to a tier 3 hub/router 115 to various local clients 116, 117, 118. Any of 

applications server 307. Also in Tier 1 a dedicated user 311 35 tDesc severs U2> 113, 114 could function as a server of the 

may be directly connected to a tier 3 applications server 307. present invention, as more fully described below. Any user 

And the tier 3 applications server 307 may be connected to Sltua ted at any of these client machines would normally have 

a database management system 309. to be an authorized user of the system as described more 

Referring now to FIG. 4, the tier 3 applications server 307 Mly below * 

is expanded in FIG. 4 to illustrate the Business Applications 40 An embodiment of the Business Applications Platform 

Platform 415 of the present invention. In FIG. 4, the System of the present invention can operate on a general 

Platform contains an Interface Server 417, an Information purpose computer unit which typically includes generally 

Server 419, an Interconnect Server 423 and a Business the elements shown in FIG. 2. The general purpose system 

Server 421. Ail of these Servers 417, 419, 421 and 423 may 201 includes a motherboard 203 having thereon an input/ 

physically resign on the same hardware platform (such as a 45 output ("I/O") section 205, one or more central processing 

UNIX box or a Microsoft™ NT™ platform), or each server units ("CPU") 207, and a memory section 209 which may or 

may reside on a separate hardware box, or any combination may not have a flash memory card 211 related to it. The I/O 

of servers and hardware boxes. Each of the servers may have section 205 is connected to a keyboard 226, other similar 

included a JAVA Virtual Machine™ and the related runtime general purpose computer units 225, 215, a disk storage unit 

support. The electronic communications between these serv- so 223 and a CD-ROM drive unit 217. The CD-ROM drive unit 

ers may use the XML protocol (409, 425, 427) with each 217 can read a CD-ROM medium 219 which typically 

server having services for translating XML into tbe partial- contains programs 221 and other data. Such programmed 

lar Applications Programming Interface (API) language computers may also be connected electronically to database 

required by the server and for translating its internal lan- systems such as those available from Oracle™, Sybase™, 

guage into XML prior to transmission to another server. In 55 Informix™, SQLServer from Microsoft™ and the like! 

a preferred embodiment, all of these servers are contained in Logic circuits or other components of these programmed 

a single tier 3 platform, and may communicate with each computers will perform series of specifically identified 

other directly without the necessity of changing the inter- operations dictated by computer programs as described more 

facing protocol format. The Interface Server 417 (also fully below, 

alternatively designated herein as the WDK), communicates 60 

through a webserver 405 via the internet 403 to web clients Dctailed System Description 
401 via the HTML protocol. The Interface Server 417, also 

may communicate to a directly connected client 407 via The Platform system of the present invention is now 

other protocols such as XSIVXSLT etc., and may commu- described in more detail. In general a preferred embodiment 

nicate to Personal Data Assistants 411 such as cell phones or 65 with a presently known best mode for making and using the 

Palm Pilots™ or other such wireless devices using wireless system is described. Alternative embodiments are similarly 

protocols such as WAP/WML, etc. The Interface Server 417, described for various parts of the Platform system. 
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Business Applications Server/BDK 
Preferred Embodiment 

The following description of the BDK Business applica- 
tion server covers the presently preferred embodiment and 
the presently known best mode for making and using it. This 5 
section is followed by a further description of an alternative 
embodiment which may include features in addition to or in 
place of those in the preferred embodiment. 

1. Overview 

The Business Development Kit applications server 10 
(BDK) component of the Platform provides a supporting 
framework for business objects. A business object is a Java 
object with persistent state that represents some entity in a 
business application, such as an employee or company. 

Specifically, the BDK provides a persistence framework 15 
for saving and restoring object state and a set of core 
services for performing a variety of useful operations on 
business objects. 

2. Persistence Framework 

20 

The persistence framework defines a common code path 
used to create new objects, restore and update existing 
objects, delete objects, and find objects. Hie code path 
consists of a set of Java code and database stored procedures 
to construct and verify object data and SQL commands to 25 
save and restore information using a relational database. 

The persistence framework is highly flexible because it is 
metadata-driven. For each class of object, the system pro- 
vides a set of metadata — data about data — that defines the 
class' properties and behavior. This means that the data used 30 
to determine the behavior and characteristics of specific 
classes and instances of business objects is stored as distinct, 
editable information, rather than being hard-coded into the 
logic of the system. The persistence code itself is part of the 
metadata, that is, the SQL commands for save, restore, etc. 35 
are stored as metadata, not in source code. As an example 
benefit, it makes applications much easier to port between 
databases because only the metadata for the SQL needs to be 
changed; no source code needs to be changed and recom- 
piled. 40 

Use of metadata allows the system to be configured and 
otherwise modified by different clients for different 
deployments, resulting in unique runtime behavior of the 
system. Object properties that can be customized range from 
the labels used to display object information, to the type of 45 
data validation performed, to the amount of custom infor- 
mation associated with each object. 

A unique feature of the persistence framework is its 
support for an arbitrary amount of custom information, 
stored in what is known as "custom fields/' Experience has so 
shown that predefined business objects typically do not 
express the full set of data a given customer may wish to 
track, and that this data varies from customer to customer. 
Custom fields provide a way for different customers to 
uniquely extend the data stored with a class of business 55 
objects. In the current implementation, customers are pro- 
vided with a set of five "custom fields" that can be searched, 
and an unlimited number of "extended custom fields" that 
cannot be searched, but provide additional data validation 
for date and numeric values. Again, the code to save and 60 
restore custom fields is all driven off metadata. 

As an example of the persistence framework's operation, 
a user of the system may attempt to create a new employee 
by specifying the employee's first and last name, social 
security number, starting salary, and date of birth. The 65 
persistence framework performs the following operations to 
save this data as a new "SabaPerson" business object: 
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Uses metadata settings about the "first name", "last 
name", "ssn", and "birth date" properties of a "SabaP- 
erson" to determine the data validation to perform. In 
this case, the metadata settings may instruct the frame- 
work to verify that values are provided for first name, 
last name, and ssn, that starting salary is greater than a 
fixed numeric minimum wage value, and that birth date 
is a valid date. 

Uses metadata to obtain and execute a database stored 
procedure named "tpp_person_ins" that takes values 
for first name, last name, ssn, salary, and birth date as 
parameters and inserts these values into a database 
table named "tpt^person." 

2a. The Meta-data Store 

In the preferred embodiment the meta-data store contains 
the definition of each type of object in the system, its 
.attributes, „and, some, basic properties of those attributes.. 
Further, for each type of object, it contains a reference to the 
methods to invoke, to insert, update, delete or fetch a given 
instance of that object from the persistent store. 

The Metadata store consists of the following tables: 

1. fgt_dd class 

Every business object in the system is registered in this 
table. This table also describes basic properties of objects. 
fgt_dd„class has the following columns: 



Column Name 


TVne 


Rq? Description 


Id 


Char (20) 


The identifier of the object 


ULjiame 


Varchar2 


This is the display name of 




(255) 


the object and generally used 
to paint UI as well. 


Description 


Varchai2 


Meaningful description of the 




(255) 


object and its function. 


Enumbcr 


int 


Unique number for each 
object. 


Insert—Spid 


Int 


Method call for inserting a 
new instance of the object 
Foreign key to mesg_id 
column of fgt_mesg_table. 


Update_spid 


Int 


Method call for updating an 
existing instance of the 
object Foreign key to 
mesg__id column of 
fgt_mesg_jable. 


Delete^spid 


Int 


Method call for deleting an 
instance of the object 

Foreign key to mesg id 

column of fgt_mesg_table. 


Scl det__spid 


Int 


Method call for retrieving an 
instance of the object based 
on its id. Foreign key to 

mcsg id column of 

fgt„mesg_table. 


Finder__id 


Int 


Finder Id for invoking a 
default finder associated 
with the object. 


Fixed_attr_ct 


Int 


Total count of the fixed 
attributes for the object 


Attr_ct 


Int 


Total count of the attributes 
for the object. This number 
is sum of alt fixed and all 
custom attributes. 


Flags 


Char (10) 


Ten bit string describes the 
behavior of the object 
1st bit = Object can be 
displayed in the security 
screen for granting privs. 
2nd bit « This 2bit mask is 
set to see if reports or 
letters or both can be 
attached. 

3 fd bit = Obsolete. 
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-continued 



-continued 



Column Name 



Type 



Rq7 Description 



Column Name type 



Rq? Description 



next_attr_enum Int 



Prefix 



Table_name 



chai (5) 



\&rchar2 
(25) 



Domain_enum int 



Java class_ 

Hlevel 
Parent_id 



Varchar2 

(255) 

Int 

Char (20) 



4 th bit - Obsolete. 

5 th bit - If the object is 

owned in nature and cannot 

exist without its owner. 

6 th bit = Obsolete 

7 th bit - If object can be 

customized bu end user. 

8 th bit - If Object can have 

Extensible attributes of its 

own. 

Enumber to use for the next 
custom attribute that will be 
added to the object The 
install time value for this 
attribute is 10,000. 
This Sletter long string is 
' " * used'in'gencrating lds'for'" 
the object This string is 
prepended to the number 
generated by the sequence. 
This is the name where the 
object is stored. The 
sequence, methods are also 
named based on this. 
This is denormalized data and 
shows the enumber of the 
Domain attribute. 
The java class name of the 
object 

The Level of the object in 
the object hierarchy. 
In case of hierarchical 
objects it stores the parent 
object's id 



5 Enumber 



Int 



15 



CoL_name Varchar Y 
(255) 

Ui_narne varchar (255) Y 



20 



description Varchar (255) 

Attr_type Int 
O 

list„of_vals OBJECTID 

25 

min_val Int 

30 max_val Int 

default_val STR 



As an example, the following are the values for a class of 
business object representing domains: 35 



id 


ui_name 


description 


enumber 


insert_spid 


ddclsOOOOOO 
000001095 


Domain 


Hierarchal 
Domain 


195 


105^0 


update_spid 


delete_spid 


sel_det__spid 


finder_id 


fixed_attr_ct 


10562 


10561 


10563 


15710 


14 


attr_ct 


flags 


next_attr_ 
enum 


prefix 


table_name 


14 


1100001100 


100000 


domin 


fgt domain 


domain_ 


.enum java 


_class_name 


hlevel 


parcnt_id 




com.saba.busobj. 
SabaDomain 


1 





40 



45 



50 



str_l 



Flags 



STR 



varchar (15) 



2. fgt_dd_attr 

The attributes of each class of business object is stored in 55 
this table. This table also describes basic properties of each 
attribute. 

fgt__dd__attr has the following columns: 

60 



Column Name Type 



Rq? Description 



Id 

Cid 



Char (20) 
OBJECTID 



Y 
Y 



Unique identifier for an 
attribute. 

The object id, this 
attribute belongs to 



Required to be unique within 
a class. The code should use 
these numbers to refer to 
attributes rather than using 
the ID. Fixed enumbers are 
assigned in the range 1000- 
9999. Extensible attributes 
are allocated from 10,000 
onwards. The next_attr_enum 
in the corresponding object 
record stores the next 
enumber available for this 
class. 

The column name in which the 
value of this attribute is 
stored. 

"The name of the attribute; "" 
which is used for painting 
the UI. 

Description of the 
attribute. 

The number corresponds to 
the data type of the 
attribute. 

If the attribute vaL is 
selected from a list of 
values, then the id of the 
list is stored here. 
If its a numeric column, 
then the min allowable value 
if any. 

If its a numeric column, 
then the max allowable value 
if any. 

Default value to use for the 
attribute when an instance 
of the object is created. 
This generation formula for 
those attributes whose 
values have to be generated 
on the creation of the 
object The generation is 
driven by the generation bit 
in the flag. 

1 M bit => The required 
bit 

2 nd bit -> Reference bit is 

set if attribute points to 

another object. 

3 rd bit -> LOV bit is set 

if its values must come from 

fixed list of values. 

4th bit »> This two bit 

mask describes the type of 

the attribute. 

5th bit => Id bit is set if 

its an Id column. 

6th bit «> Generation bit 

is set if the value need to 

be generated during the 

creation of an object 

7th bit => Customization 

bit This 4bit mask says if 

Label, required or 

generation can be customized 

by end user. 

8th bit => Audit bit 

9th bit => Obsolete 

10th bit -> Obsolete 

11 th bit => This bit 

describes the type of the 

custom attribute. 

12 th bit => Domain bit is set 

if the attribute is domain 

id. 

13 th bit «=•> set if Defeult 
value can be changed by 
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-continued 



Column Name Type 



Rq? Description 



user. 

14* bit "> set if Minimum 
value can be changed by 
user. 

15 th bit => set if Maximum 
value can be changed by 
user. 



18 



10 



As an example, the following are some of the attributes 
defined for the domain business object: 



fgt_mesg__table has the following columns: 



Column Name Type Rq? Description 

Mesg_id Int Y This is the message id for 

the SQL statement group. 

Mesg_seq Int Y Since the SQL statements can 

be greater than 255 chars 
which is the length of the 

tncsg text columns. This 

column tells the sequence of 
this SQL statement in the 
group. 



id 


cid 


enumber 


col_name 


ui_name 


attr_type 


flags 


ddatrOOO 


ddclsO 


1000 


id 


ID 


8 


100011000 


0000000 


00000 










000000 


02991 


00000 
1095 












ddatrOOO 


ddclsO 


1001 


time stamp 


Time Stamp 


4 


100000000 


0000000 


00000 










000000 


02992 


00000 
1095 












ddatrOOO 


ddclsO 


1002 


name 


Domain Name 


4 


100000100 


0000000 


00000 










000100 


02993 


00000 
1095 












ddatrOOO 


ddclsO 


1003 


description 


Description 


7 


000000300 


0000000 


00000 










000100 


02994 


00000 
1095 












ddatrOOO 


ddclsO 


1004 


cuslomO 


customO 


7 


000100300 


0000000 


00000 










010100 


02995 


00000 
1095 













3. fgt_jnesg__table 



This table stores the actual SQL code used for object 
persistence. In the case of insert, update, and delete methods, 
typically these are calls to stored procedures containing 
additional business logic in addition to database calls. 



Long SQL statements are stored in multiple rows, which are 
then reconstructed on-the-fly by the persistence layer. 



continued 



Column Name 


Type 


Rq? 


Description 


Mesg_text 


Vfcrchar 


Y 


The text of message. 




(255) 







As an example, the following are persistence calls for the 
45 domain business object. Note from the sample data above 
that 10563 is the code for retrieving an object, 10560 for 
inserting an object, and 10562 for updating an object. 



mesg_Jd mesg_Beq mesg_text 



10563 


1 


select did id, d.time_stamp ts, d.name 
dname, ddescription descr, d.customO cO, 
d.customl cl, d.custom2 c2, d.custom3 c3; 
d.custom4 c4, d.created_on cron, dLcreated_by 
crby, d.updated_on upon, d.upd 


10563 


2 


ated_by upby, d.parent_id pid, parent,name 
parent from fgL_domain d, fgt_domain parent 

where d.id - @001 and d. parent id - 

parcnt.id(+) 


10560 


1 


begin fgp_domain_ins (@00l, @002, @O03, @004, 
@005, (§006, @007, @008, @009, @010, @011, 
@012, @013, @014, @015); end; 


10562 


1 


begin fgp_domain_upd (@001, @O02, @003, @004, 
@005, @006, @007, @008, @009, ©010, ©011, 
@012, @013, @014, @015); end; 
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Notice that the SQL references the actual table used to 
store domain data, fgt_domain (described in detail in the 
section on security}. 

The fgp_domain_ins stored procedure is PL/SQL code 
defined as: 

create or replace procedure fgp J3 domain_ins 



create or replace procedure fgp__domain ins 

( 

xid char, 

xtime_stamp varchar2, 

xname varchar2, 

xdescription varchar2, 

xcustomO varchar2, 

xcustoml varchar2, 

xcustom2 varchar2, 

xcustom3 varchar2, 

xcustom4 varchar2, 
xcreated_on " "" date, " — 

xcreated_by varchar2, 

xupdated_on date, 

xupdated_by varchar2, 

xparent_id char, 

xnewts varchar2 
) 

as 

begin 



10 



Every SabaObject is expected to know which class it 
belongs to, and how that class is registered in the 
meta-data store. Thus each subclass of SabaObject 
stores a class identifier so that it can tell the system 
which entry in the meta-data store it corresponds to. 

Every SabaObject also stores a state flag that determines 
whether this is a new object, or it is an object that 
already exists in the data store. This state then deter- 
mines whether the object invokes an insert method or 
an update method during a save( ) invocation. 

Every SabaObject has an unchangeable, unique identifier 
that identifies that particular object in the persistence 
store. The uniqueness of this identifier is guaranteed 
across the entire persistence store regardless of the type 
of object. 



20 The algorithm for save is then as follows: 



Look up the entry for the class of the object in the 
meta-data store. 



25 



30 



35 



40 



45 



r validating that the parent of a node is not 

itself */ 

if (xid = xparent_id) then 

rai$e_ J appIication_error(-20698, "); 

return; 
end if; 

r parent_Jd cannot be null except for the root V 
if (xid <> 'dominO 00000000000 001 ' and xparent_id is 

null) then 

raise_application_error(-20699, "); 
return; 
end if; 

insert into fgt_domain ( 

id, time_stamp, name, d_name, description, 
customO, customl, 

custom 2, custom3, custom4, crcated_on, 
created_by, updated_on, 

updated_by, parent_Jd) 
values ( 

xid, xnewts, xname, lower(xname), 
xdescription, xcustomO, xcustoml, 

xcustom2, xcustom3, xcostom4, sysdatc, 
xcreated_by, sysdate, 

xupdated_by, xparent _id); 
l M update the deformalized flat tree tabic */ 
tpp_flaL_tree_relation(195, xid, null, null, 0); 
/* inherit a snapshot of the custom fields for all 

objects */ 

insert into fgt_dd_domain__to_attr 

(ID, TTME_STAMP, DOMAIN _ID, ATTR_ID, FLAGS, 
LOCAL_FLAGS, UI_NAME, MIN_VAL, 

MAX_VAL, DEFAULT- VAX, UST_OF_VALS, 50 

GEN_MASK) 

select 'ddoat'H 

IpaclOtrim(rtrim(to_char(f^ 15, 
'0'), 

xnewts, xid, ATTR_[D, FLAGS, LOCAL_FLAGS, 
UI_NAME, MIN_VAL, 

MAX_VAL, DEFAULT— VAL, LIST_OF_VALS t 

GEN__MASK 
from fgt_dd_domain_to_attr 
where domain_id = xparent_id; 

end; 

" 60 

2b. Persistence Algorithms 

In a preferred embodiment all business objects that Saba's 
Application server manipulates are derived from a single 
base class called SabaObjecL The SabaObject class provides 
save, restore, and delete capabilities by implementing the 65 
persistence layer architecture. All subclasses of SabaObject 
then inherit this behavior and rarely if ever override it. 



55 



If the class is notfound, raise an error "Unknown Class". 
If (State-new) 

M=look up the method to call for inserting the object. 
Else /* State-update */ 

M=look up the method to call for updating the object 

Marshall all the attributes of the SabaObject into the 
appropriate data structure. 

Check each of the attributes against the rules set for its 
nullity, constraints. If any of the constraints are 
violated, throw an error. 

Lead the default values wherever necessary. 

Invoke M with that data structure. (1) 

For deletion, the basic process is identical, except that the 
invocation of the delete method only requires the unique 
identifier of the SabaObject to be passed in as its only 
argument. 

For restore, the algorithm is just slightly different and is 
as follows: 

Look up the entry for the class of the object in the 
meta-data store. 

If the class is notfound, raise an error "Unknown Class". 
M=look up the method to call for fetching the object. 
Invoke M(unique ID of SabaObject) 
Unmarshall all the attributes returned by M (2) 
In the presently preferred embodiment, the method invo- 
cation currently only supports invocation of database stored 
procedures although in alternative embodiments this will be 
extended to other types of persistence mechanisms. 

These stored procedures provide the actual intelligence of 
taking the marshaled arguments that come in, and storing 
them in specific Belds in the database, and vice versa. Thus 
a combination of the meta-data store and the stored proce- 
dures create an abstraction layer that allows the base 
SabaObject to store all objects through a simple, uniform 
algorithm. 
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|Fctch Method] 




The persistence mechanism thus created allows the trans- 
fer of various kinds of objects to database storage as shown 
below. 



IQbject 1 




|Objcctl| |Object 2[ 




Fig 1 Single object to 
a single table 



Fig 2: Two objects to a 
single table 




Fig 3. Single object to 
two tables 



Fig 4: Object with calculate 

fields that do not physically 
exist in the table 



|Objectl| 

X. 

Hill 

Fig 5: Object does not have 

denormalized fields thar 
exist in the table 



2c. Configurable Custom Fields 

In the preferred embodiment, the Saba persistence mecha- 
nism provides built-in support for configurable, runtime 
definable, custom fields for any object. 
5 The basic mechanism is extremely simple. An adminis- 
trative user interface is provided by which the meta-data 
definition of a given class can be extended by adding (or 
removing) custom attributes as needed. For each custom 
attribute, the user only needs to provide some very basic 
10 information about the type of the field, whether or not it is 
required, constraining minimum and maximum values for 
numeric fields, and a constraining list if the field is to be 
validated against a list of possible values. 

The SabaObject implementation then simply picks up 
15 these fields during its normal marshalling and unmarsh ailing 
of arguments. Further, the SabaObject also performs the 
basic checks for nullity as it would normally do. 

To save" and restore the custom fields, the * actual algo- 
rithms are extended from the ones shown earlier. In the case 
20 of insert or update the following additional lines are called 
after the line marked (1) in the algorithm shown earlier: 
After invoking the basic method M 
Marshall all custom field data into the appropriate data 
structure 

Invoke the insert/update method for storing the custom 
data structure. 

In the case of restore, the following lines are added to the 
original algorithm after the line marked (2): 
Invoke the custom field fetch 

Unmarshall all custom field data and update the relevant 

fields in the SabaObject. 
The actual storage where the custom field data for any 
given instance is stored, consists of a single table as defined 
below. All the custom field data is stored as tag-value pairs 
in typed columns. 
Fgt_dd_custom 

This common table provides the storage area for all data 
stored in the extended custom fields for a given object. 

40 
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Individual messages are retrieved using a SQL command 
of the form: 

select mesg_Jd, mesg_seq, mesg_text from fgt_mesg_ 

table where mesg id=? order by mesg_Jd, mesg seq 

Query results are transformed into actual SQL code using 
the following method: 



private static String processMessage(ResultSet rSet) 
throws Exception, Saba Exception 

{ 

StriogBuffer buf; 
String str, 

buf = new StiingBuffcr (rSctgctStrbg(kMsgTbxtCol)); 
while (rSetnextO 1= false) 
{ 

String temp » rSctgetString(kMsgTextCol); 

bufappend (temp); 

} 

str - buftoStringO; 
return str; 





Column Name 


Type 


Rq? 


Description 




Id 


OBJECTID 


Y 




45 


owner_id 


OBJECTID 


Y 


Which object this custom 








field is for. 




attr _jd 


OBJECTID 


Y 


Refer to the attribute 
for which value is 
stored. 




attr type 


INT 


Y 


Type of the custom field. 
This matches the attr type in 


50 








the fgL_dd_attr table and is 
a denormalization of the 
same. 




Num_value 


Number 


N 


Value is stored here if it is 
Numeric type 




Str_yalue 


Varchar 


N 


Value is stored here if 


55 
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it is String type 




Date value 


Date 


N 


Value is stored here if it is 
Date type 



Retrieved messages arc also stored in a local cache for improved 
performance. 



3 Core Services 
60 BDK also provides a set of core services to perform useful 
operations on business objects. Some of these services 
include: 

Security. BDK provides extremely fine-grained security 
control to control whether specific users have privileges 
65 to perform operations such as creating or viewing a 
particular class of business object. The system is unique 
in that it provides a flexible model of security roles and 
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security lists to assign a set of privileges to distinct 
groups of users, and it employs a scalable notion of 
domains to differentiate among sets of business objects. 
The security model is explained in detail in a separate 
section below. 

Auditing. BDK provides the ability to track the history of 
all changes to an object, including the date of a change, 
the identity of the user making the change, and a 
justification for the change. 

Internationalization (il8n). BDK provides utilities for 
allowing business objects to be internationalized. Inter- 
nationalization is a standardized process wherein mes- 
sage content, money amounts, dates and various other 
culture specific data are kept in separate files in order 
to permit an easy change from one countries language 
and cultural rules to another. This comprises both 
storing values of business objects in multiple languages . 
and supporting multiple formats for date, currency, and 
other data types that vary among countries. 

Concurrency. BDK provides concurrency services for 
controlling overlapping write operations on multiple 
instances of an object, while permitting multiple reads 
at the same time. This is achieved via comparison of an 
instance -specific timestamp when committing of an 
object's state to the persistent store is requested. The 
timestamp is updated whenever the state of an object is 
altered and the object is successfully committed to 
persistent storage. 

Transaction Management. BDK provides two types of 
transactional services: procedural and declarative. In 
the former case, a developer explicitly marks the begin- 
ning and end of a unit-of-work using BDK's API. In the 
latter case, a developer can associate a transactional 
attribute with a method, and the BDK's Transaction 
Monitor keeps track of initiating and terminating 
transactions, as well as executing a method within the 
scope of an on-going transaction, based on run-time 
context. 

Logging. BDK provides logging functionality that can be 
used for capturing system state and operations in one or 
more logs. 

Notification. BDK provides the ability to send 
notifications, such as emails or faxes, to predefined 
categories of users when the state of identified business 
objects changes. For example, everyone subscribed to 
a class may receive a page if the class is cancelled. 
Business Rules. In a preferred embodiment, for example, 
Saba's learning application provides a set of pre- 
defined business rules that affect the workflow and 
behavior of various business objects in the system. The 
BDK provides a mechanism to enable and disable these 
business rules. For example, a customer can configure 
whether a manager's approval is required to register for 
a class. Similar business rules can be handled for other 
types of applications. 
Notes, BDK provides the ability to associate arbitrary, 
free-form text, or "notes," with any business object in 
the system. 
4 Application Programming Interfaces 
In the preferred embodiment, the BDK exposes Applica- 
tion Programming Interfaces (APIs) for use in programming 
the system. A variety of APIs with equivalent functionality 
are supported on top of the persistence framework. The 
system supports both propriety and industry-standard forms 
of Java API, as well as XML-based APIs. 
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a. SabaObject API 

One Java API is a proprietary "SabaObject" interface to a 
business object. A SabaObject is a Java class defining a set 
of operations common to all business objects, including the 
5 ability to get and set properties using a variety of data types 
and the ability to save and restore an object's state. Specific 
business object classes can subclass SabaObject to add 
functionality and business logic appropriate to that class. 
The Java interface for SabaObject is the following: 

10 



public class SabaObject { 

r* 

* SabaObject Constractor 

15 * Creates a new empty Saba object in the context of the 

given session. 

•/ 

public SabaObject(String session Key); 

~/*' methods to set attribute values as" different datatypes - ' 

7 

2Q public void setAttrVal(String attrName, Boolean attrVal); 

public void setAttrVal(String attrName, Tunes tamp 

attrVal); 

public void setAttrVal(Siruig attrName, Integer attrVal); 
public void setAttrVal (String attrName, BigDecirnal 

attr\kl); 

public void setAttrVal (String attrName, String attrVal); 
25 public void setAttrVal (String attrName, Object attrVal); 

/* methods to restore attribute values as different 
datatypes */ 

public String getAttrVal(String attrName); 

public String getStringAttrVal (String attrName); 

public Integer getIntegerAttrVal(String attrName); 
30 public Times tamp gptTimestampAttr\fel(Stririg attrName); 

public BigDecimal getBigDecirnalAttrVal(String attrName); 

public Boolean getBooleanAttrVal(String attrName); 

r * 

* Gets a hashtable of the attribute values. 
7 

35 public Hashtable getAttributeVblues 0; 

/** 

* Returns the display label for the named attribute 
7 

public String getAttribute Label ( String attrName); 
/* save, restore, and delete methods */ 
public void saveQ; 
public void savc(SabaTransaction tr); 
public void restore^); 
public void restore(SabaTransaction tr); 
public void delcteO; 
} 

4S 

In the preferred embodiment, as part of a business object's 
creation, the business object author provides four SQL 
statements corresponding to selection, deletion, insertion, 
and updating of the object. Pointers to these statements are 

so provided as part of the metadata for the object as stored in 
fgt__dd_class. The first two (selection and deletion) types of 
statements take a single bind variable, namely, the id of the 
object. The other two take the id as well as all other attribute 
values in the order declared in the metadata for that object's 

55 attributes in the table fgt_dd_attr. The order of retrieval of 
attributes in the selection statement must also match such 
order. 

Upon receiving a request to create an in-memory repre- 
sentation of an object through the "restore( )" method, BDK 

60 retrieves the selection statement for that class of objects, 
binds the variable to the id of the object that is desired to be 
restored, executes the statement, and fills in an instance- 
specific hashtable of attribute-value pairs with the values so 
retrieved. In addition, a standard SQL statement is executed 

65 to retrieve the value of extended custom attributes, and the 
results are again inserted in the aforementioned hashtable. 
For the "restore(SabaTransaction tr)" variant of this 
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operation, the execution of these SQL statements is done 4c. Session Manager APIs 

using the database connection contained in tr, the transaction The EJB model also has a notion of "session beans," 
argument. When executing the w delete( )" method, the object higher-level interfaces that represent business processes. In 
is marked for deletion. Upon a subsequent call to "save( )" the preferred embodiment, the BDK has standardized on the 
or w save(SabaTransaction tr)," BDK checks for the state of 5 useof session bean-based interfaces as its public API; these 
the object. If it is an object that has been marked for deletion, interfaces are known as "session bean managers," and are 
the deletion SQL statement as supplied by the business implemented using the lower-level entity bean APIs pro- 
object author is executed after binding the id, using the vided by the persistence layer. The BDK provides a 
database connection in the transaction argument for the SabaSessionBean base class that defines common session 
"save(SabaTransaction tr)" case. Other possibilities upon 10 bean manager functionality, and a framework for several 
execution of the save operation are that the object instance categories of "helper classes"— additional interfaces used in 
is new, or it is an altered state of an existing object. In these conjunction with specific session bean managers: 
cases, the statements corresponding to insertion and updat- ™ ♦ -i * • * ui j * -i ■ r t_ 
ing are executed, respectively, after the replacing the bind ^tail-represent immutable detail information about a 

variables with attribute values from the hashtable in the 15 busmeSS ° bjeCt 

order specified in metadata. In the case of insertion, BDK Handle— represent opaque references to a business object 

automatically generates a unique idjbr the object that is Primitive — represent commonly used data structures, 

reflected both in the persistent storage and me fi-memory such* as ; "addresses and full' names 

representation. 4d. XML Interfaces 

Implementation of the setAttrVal( ) and 20 In m e preferred embodiment, the BDK also provides 

get<type>AttrVal( ) involve setting and accessing values in XML-based interfaces for saving and retrieving business 

the hashtable, respectively, using the provided attribute objects; these interfaces provide the communication layer 

name as the key. getAttributeValues( ) returns a copy of the with the other Platform servers and components, 

object's hashtable whereas getAttributeLabel( ) looks up the One XML format is known as "Saba Canonical Format" 

attributes* metadata and returns the label corresponding to 25 (SCF). ItisanXMLserializationof the data in a SabaObject. 

the chosen attribute. The Interconnect server system reads and writes SCF to 

4b. SabaEntityBean API implement the AccessorReader and ImporterWriter for the 

Another Java API is based on the industry-standard Enter- native Saba system; refer to the Interconnect server section 

prise JavaBean (EJB) model. This model has a notion of for more details. 

"entity beans" that provide the interface to specific business 30 ^ example fragment of an SCF document, representing 
objects. Accordingly, the persistence framework provides a a business object defining a specific currency, is: 
EJB-based abstract class, "SabaEntityBean" that imple- 
ments the javax.ejb.EntityBean interface. The SabaEntity- 
Bean class provides default implementations of the follow- 

tag methods: ejbActivate( ), ejbPassivate( ), ejbRemove( ), 35 ^^Xo^^^^ 

setEntityContext( ), ejbCreate( ), ejbLoad( ), ejbStore(), and <name dt:type="strin£*>us Dollars </mmc> 

unsetEntityContext( ). Implementations of the ejbLoad( ), <time_stamp 

ejbStore( ), ejbCreate, and ejbRemove( ) methods rely on the dt:t ypc »" 5 triiigvi998i2i6i647032900</tiinc^t a mp> 

i j * • .ji i <short_name dt:type=."stnng**>USD</short„name> 

selection, update, insertion, and deletion statements declared ^ dt:type-"str^'>iioa)00000^flag 9 > 

as part of metadata (please refer to the discussion of the <^SabaObject> 
implementation of SabaObject's API). Other methods are 



implemented as empty stubs that can be overridden by a r r , u # 4 ; ™ „ . 4 - 

developer if desired. f . fa embodiment another XML interface is 

In addition to defining the bean class, to implement an ^ ™™*f ^ ™^ » 3 J ™ 

EJB one also needs to define a corresponding remote 45 f^^* of serializing itself ir^o an XML represento- 

interface, a home interface, and, for entity beans, a primary ti ° n : ™ e K detail > handle > P nm f ltive Mp« 

key class. The remote interface is the external world's view bea ° m ^ n this ™ e 

of the bean and is comprised of the business methods that the w ™ Cs «v« system uses these objects to generate dynamic 

bean wishes to expose The getters and setters for the bean's ™* T £ ST? XiT 

attributes are also exposed tfioqgh the remote interface. The 50 ^t^^J!^^^ U 

home interface declares the life-cycle methods, such as those ™ ^ ^ , T'' * . ,u w » 

f^r ~ k~ The IXMLObject mterface conforms to the "Visitor" 

for creating, removmg or finding beans. ^ ^ 

In the preferred embodiment, the BDK provides two 6 * 

interfaces, ISabaRemote and ISabaHome, which a bean can 

extend for defining remote and home interfaces, respec- 55 

lively. The ISabaRemote interface extends the standard EJB public interface rxMLObject { 

interface EJBObject and provides the following sets of /** 

methods: * Accept a visitor. An implementation should ask the 

Visitor to visit each of its public elements (Le. 7 fields or 

void setCustomAttrVal(String attr, <type>value), and properties). 

<type>getCustomAttrVal(String attr) * _ . . _ 

' * @param visitor The XML Visitor object 

for Boolean, Timestamp, String, Integer, Float, and */ 

Double data types. The ISabaHome interface provides ■ pub\ic void acccptXMLVisitor(lXMLVisitor visitor) throws 

a layer of abstraction over the standard EJB interface XMLVisitorException; 

EJBHome. The BDK also defines a class SabaPrima- 65 ^ ^ teg ^ foT ^ objccL 

ryKey (a thin wrapper around the String class) which * ©return the tag name to identify 
can be used by entity beans for defining primary keys. 
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In the alternative embodiment, the following discussion 
-continued of is background for a discussion of the usage and types of 

~ EJBs within the context of the development kit described in 

public String gemgNamcO; m ° re detail bel ° W ' 

} 5 Metadata Support 

In the alternative embodiment, one of the facilities pro- 



Note: . •Visitor'' object is one which has processes which represent an vided 5y thc development framework is that characteristics 

operation to be performed on the elements of an object structure. A visitor c , , • , . . , , . , „ 

lets oqc define a new operation without changing the classes of the cle- of business objects can be varied across deployment. For 

ments on which it operates. Visitor objects and their operation and use are example, for an attribute, One can Optionally Specify whether 

described inmore detaU at pages 331-344 of Design Patterns, by Gamma, 10 it has a required attribute, the list of values (LOVs) that the 

Helm Johnson ft Vjissides, AddisoQ-Wcsley 1995, ISBN 0-201-63361-2 a(tribute ^ ^ {if . defauU yahl and its minimum and 

which are hereby fully incorporated herein byreference. Those skilled in . , ' 7 , 

these arts wall recognize that various other implementations of these algo- maximum values. The values can be different across 

rithms and concepts may be developed without departing from the spirit installations, as different customers have different require - 

and functionality of this invention. Additional background information can ments. To achieve this flexibility, metadata about the busi- 

be found in Enterprise ^ JavaBeans Specification, vl.l (can be found at url- 15 ness and meir attr ib u tes is captured in the system. 

java.suac»nVproducts/cjb/ docs.html), and mother sections of the book T „ tU ~ „ u , ,. . r*u * j \ iL . 

tilled Design Patterns, by Gamma, Helm, Johnson, & Vlissides, Addison- . Io the alternatlVe embodiment, SO me of the metadata that 

Wesley 1995, ISBN 0-201-63361-2 which are hereby fully incorporated is currently captured about a class or an attribute could be 

herein by reference. — ■ - dynamically determined using the Java* reflection API: • 

Alternative Embodiment Examples include the parent ID and attribute count for 

An alternative embodiment of the BDK business appli- 20 business objects and attribute type for an attribute. The Java 

cations server may be described as follows, using the context reflection API provides classes Class and Field that can be 

of how a developer and user would use this portion of the used to retrieve such information. Furthermore, instead of 

system. In an alternative embodiment, the developer's use is building a hashtable-based infrastructure for storing and 

outlined in the context of a BDK development kit which retrieving attribute values, one can use methods like set and 

would be provided by Applicants for use in developing 25 get in the Field class to operate directly on the attributes, 

applications which can run on the Platform and by way of which are declared as member variables of the class, 

indicating some details unique to the Platform through a The classes Class and Field by themselves, however, may 

description of a use of the Business Development Kit not provide the rich functionality needed by certain appli- 

In the alternative embodiment, the Business Server cations. For instance, there is no way to indicate minimum 

embodies a development kit framework which provides a set 30 and maximum values of an attribute in the Field class. Thus, 

of interfaces and classes in the form of Java packages, what is needed is to create new classes that provide wrappers 

identifies certain services that developers can rely on, and around aass ^ Field ^ capture the additional informa- 

defines an application development model. The framework tion . In the ^ksI of consistency with previously used 

relies extensively on the server-side component model Dames whlle avoidin at £ e same time, tW o new 

t y jT' n Tp^J f ^ ^^(V*)™*- 35 classes maybe used! SabaPlatformClass (inherits from 

ponents. Selection of EJBs as the server-side component ™ ~\ j o u ™ *c a*. * /* i. c r - u\ w 

model is driven in part by the requirements of reliance on ™? SabaPlatformAttnbute (inherits from Field). In 

open standards and backward compatibility. Using EJBs *d™on to the functionality provided by Class (e.g., for 

also enables integration with other Java 2 Enterprise Edition getting parent class), SabaPlatformClass provides for such 

(J2EE) technologies such as Java ServerPages (JSP) and additional functionality as domain-based attributes and get- 

servlets that one would intend to use for web applications 40 ^ fixed ^ exte nded custom attribute counts. Similarly, 

development Furthermore, a number of EJB-enabled appli- SabaPlatformAttribute provides functionality for LOVs, 

cation servers available in the marketplace could be used to default value, and minimum and maximum values. (As we 

deploy the components so developed. will discuss later, the classes SabaPlatformClass and Saba- 

In the alternative embodiment, the development kit PlatformAttribute themselves are beans— or, entity beans to 

classes and interfaces, the services, and the application 45 be more specific — in this alternative embodiment system.) 

development model are discussed in greater detail in the The classes SabaPlatformClass and SabaPlatformAt- 

next three subsections. tribute will not be used directly by users of business com- 

Qasses and Interfaces ponents (though developers of such components will use 

The BDK interfaces and classes address the following them). Typically, the user of these classes will be a class 

° ee f? s ; e . . 50 SabaPlatformObject. In some instances, SabaPlatformOb- 

1. Provide an additional layer of abstraction (by writing ject win make ^ of te functionality provided by these 
wrappers around base Java classes) to provide a richer classes ^ art of ^ operatiorj (e . gi) when setting the value 
Ii^ 0 ^r° na ^ yn H e dedb y S ^ Aa PP hcatlonsand to of an attribute, SabaPlatformObject will use SabaPlatfor- 
dienl a^afe fS _ ^ ^ tribute to determine the minimum and maximum value 

2. Expedite component development by providing default 55 COD f traints )' ^ other cases, ^baPlatfomiObject will del- 
implementations (that can be overridden) of certain cgatc f n a?**** directly to one of these classes (an 
required interfaces in EJB. example would be retrieving the superclass of an object). 

3. Define certain interfaces that must be implemented by SabaPlatformObject implements a set of methods for getting 
classes used for specific purposes (an example is that a and attribute values that provide a centralized point 
class must implement a certain interface if its instances 60 for capturing the logic for such things as auditing and 
are used in a JSP page). constraint checking, and are used by subclasses of SabaP- 

4. Define certain classes mat are necessary to provide basic latformObject. 

services, such as data partitioning and logging, as well as In this alternative embodiment, a component user will not 

utility classes for expedited application development. interact directly with even SabaPlatformObject. Instead, the 

5. To the extent possible, eliminate application server depen- 65 component user will deal with a specialization of either a 
dencies in areas where the EJB Specification is currently SabaEntityBean or a SabaSessionBean, which are discussed 
not vendor independent. in the next subsection. 
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Beans 

In the alternative embodiment, components based on 
Enterprise JavaBeans (EJBs) will be a basic building block 
for developing applications using the BDK Below we 
provide a brief overview of EJBs. Those skilled in these arts 5 
will understand that various books and documents on the 
"java-sun-com" web site provide additional details on this 
subject. There are two types of EJBs: 

1. Entity Beans, and 

2. Session Beans. 

Entity beans are used for modeling business data and 10 
behavior whereas session beans are used for modeling 
business processes. Examples of entity beans could be 
SabaClass (a training class, not a Java class), SabaPerson, 
and SabaRegistration. Entity beans typically would map to 
objects (tables) in the persistent data store. Behaviors asso- 15 
ciated with an entity bean typically would relate to changing 
the data in the bean. 

" An example of a session bean cduld^be^ SabaRegistrar, " 
which uses the entity beans mentioned above and encapsu- 
lates the business logic associated with certain tasks, such as 20 
registering for a class. Session beans are not persistent, 
though changes in data of certain entity beans or their 
creation or removal could result from the actions of a session 
bean. A session bean can be statefiil or stateless. A stateful 
session bean maintains state information specific to the 25 
client using it, such that results of invocation of a method 
may depend upon the methods invoked earlier on the bean. 
(An example of a stateful session bean would be 
SabaShoppingCart, which would keep track of items in an 
order as they are being added, to be followed by either 30 
placement of the order or clearing of the cart.) This is 
typically done by storing client-specific data in instance 
variables of a bean, which are then used by the methods to 
accomplish their task. A stateless session bean does not 
maintain any state specific to a client. An example of a 35 
stateless session bean would be SabaTaxCalculator, which 
provides methods for computation of sales and other taxes. 

In the alternative embodiment the development kit would 
provide two abstract base classes: SabaEntityBean and 
SabaSessionBean. (Whether a session bean is stateful or 40 
stateless is indicated in something called a deployment 
descriptor.) These classes implement the javax.ejb. Entity- 
Bean and javax.ejb.SessionBean interfaces, respectively. 
The intent is to provide a default implementation of certain 
required methods to enable rapid development of 45 
components, yet allow a component to override the default 
implementation of the methods it chooses. The SabaEntity- 
Bean class provides default implementations of the follow- 
ing methods: ejbActivate( ), ejbpassivate( ), ejbRemove( ), 
setEntityContext( ), ejbcreate( ), ejbLoad( ), ejbStore( ), and 50 
unsetEntityContext( ). Implementation of the ejbRemove( ) 
and ejbCreate( ) are discussed in the next subsection. The 
other methods in the list by default have an empty imple- 
mentation. The SabaSessionBean class provides default 
(empty) implementations of the first four methods in the 55 
preceding list SabaEntityBean inherits from SabaPlatfor- 
mObject and provides attributes common to all the entity 
beans, (such as namespace) and has a method to XML( ) that 
ensures that all entity beans will provide an implementation 
for serializing their data to an XML representation. In other 60 
words, SabaEntitybean implements an interface ISabaXM- 
LRenderable (explained later) and provides two conve- 
nience methods: findUsingRQL (String rql) and findUsin- 
gRQLURI (String URI) to locate specific entity beans using 
RQL. es 

In addition to defining the bean class, to implement an 
EJB one also needs to define a corresponding remote 
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interface, a home interface, and, for entity beans, a primary 
key class. The remote interface is the external world's view 
of the bean and is comprised of the business methods that the 
bean wishes to expose. The getters and setters for the bean's 
attributes are also exposed through the remote interface. A 
developer must implement these methods by calling the 
getAttrval( ) and setAttrVal( ) methods available in SabaP- 
latformObject to take advantage of services like constraint 
checking and auditing. The home interface declares the 
life-cycle methods, such as those for creating, removing, or 
finding beans. 

The development kit provides two interfaces ISabaRe- 
mote and ISabaHome, which a bean can extend for defining 
remote and home interfaces, respectively. The ISabaRemote 
interface extends the standard EJB interface EJBObject and 
provides the following sets of methods: 
void setCustomAttrVal(String attr, <type>value), and 

<type>getC^tomAttrVal(String attr)< - - 

for Boolean, Timestamp, String, Integer, Float, and 
Double data types. The ISabaHome interface provides 
a layer of abstraction over the standard EJB interface 
EJB Home. The BDK also defines a class SabaPrima- 
ryKey (a thin wrapper around the string class) which 
can be used by entity beans for defining primary keys. 
One final interface defined in the BDK for EJBs is 
ISabaXMLRenderable. This interface extends the java.i- 
o.Serializable interface and defines a single method, 
toXML( ). Only classes that implement this interface are 
eligible to act as return types of methods that are going to be 
invoked from a Java ServerPage. 

In the alternative embodiment the BDK would come with 
a few prepackaged beans. One is a stateless session bean 
named SabaPlatformLogin that can be used to authenticate 
a user. Another is an entity bean named SabaNameSpace, 
which encapsulates characteristics of a namespace, includ- 
ing its place in the hierarchy and the list of users who have 
access to entity beans in that namespace. The namespace is 
used for data partitioning and security purposes. 
Relationships 

Another area in which the BDK provides support is 
relationships amongst entity beans. In an object model, 
relationships between different classes are arranged in four 
categories: inheritance, association, composition, and aggre- 
gation. During implementation, the inheritance relationship 
is captured by extending a subclass from a superclass. The 
other three types of relationships entail constraints between 
the classes being related. For instance, a composition rela- 
tionship implies commonality of life span (i.e., destroying 
the "whole" should result in destruction of the 
"components") and an association relationship implies ref- 
erential integrity constraints (i.e., creating an instance of a 
class which refers to a non-existent interface of another class 
is not permitted). In an alternative embodiment, such rela- 
tionships can be captured through constraints in the data- 
base. 

In the alternative embodiment, the BDK will provide a 
SabaRelationship class, that has attributes for the name of 
relationship, the type of relationship, the source class and 
attribute, and the destination class and attribute. The 
SabaRelationship class will encapsulate lifetime manage- 
ment constraints implicit in each of the different types of 
relationships. Thus, if an object is being removed and it is 
declared to have compositional relationship with some other 
objects, the SabaRelationship class will ensure the removal 
of the related objects. Similarly, when creating an object, the 
SabaRelationship class will ensure that referential integrity 
constraints are being satisfied. The SabaEntityBean class 
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will delegate calls to the SabaRelationship class within its 
ejbRemove( ) and ejbCreate( ) methods. Any implementa- 
tion that a component developer provides for these methods 
for a specific bean would have to call super.ejbRemove( ) or 
superxjbCreate( ) as appropriate. 5 

In the alternative embodiment, an attribute capturing the 
list of relationships (where each item in the list is of type 
SabaRelationship) will be defined in the SabaEntityBean 
class. By default (i.e., at SabaEntityBean level), the list will 
be defined to be empty. When component developers create 10 
an entity bean by extending SabaEntityBean, they will be 
able to declaratively specify relationships between the bean 
being created and the other beans in the system. Additional 
relationships may be added to existing beans too when a new 
bean is created. 15 

In the alternative embodiment, besides lifetime 
management, the declared relationships could also be used 
for "navigational purposes within the 'object modelrAs an * 
example, consider a situation where the SabaRegistration 
bean is related to the SabaClass bean, which in turn is related 20 
to the SabaLocation bean. One would like to be able to 
retrieve attributes of the location (say, the map) of the class, 
given a registration. A new class, SabaCompositeRelation- 
ship will allow one to compose navigational paths in terms 
of basic SabaRelationship objects. Then, given a source 25 
object and the name (or id) of a composite relationship, the 
SabaCompositeRelationship class will be able to fetch the 
destination objects). 

Vendor-specific Wrappers 

In the alternative embodiment, when some areas within 30 
the J2EE specifications are still not standardized and are left 
up to individual vendors for implementation, additional 
facilities will be needed. To prevent vendor-specific imple- 
mentation details from migrating into SABA code, the BDK 
would provide a class SabaJ2EEvendor that provides a 35 
wrapper around vendor-specific implementations. 
SabaJ2EEVendor provides static methods that can be used to 
perform activities in a vendor-neutral fashion in SABA code. 
An example method in SabaJ2EEvendor is 
getInitialContext( ),which encapsulates the logic for getting 40 
an initial context (at present, the mechanism for this is 
vendor-dependent). To use a particular vendor's implemen- 
tation of J2EE specifications, one will have to provide 
implementations of the methods in this class. By default, the 
BDK will provide implementations of this class fbr a few 45 
selected J2EE servers. 

Miscellaneous Classes 

In an alternative embodiment, in addition to the 
foregoing, the BDK also provides the following utility 
classes that can be useful for developing components: 50 
SabaProperties, DateUtil, FormatUtil, LocaleUtil, 
SystemUtil, and Timer. Also, the following exception 
classes are supported: SabaException, 
SabaSecurity Exception, Saba Fatal- Exception, 
AttributeNotFoundException, and SabaRelationshipViola- 55 
tionException. For logging purposes, the BDK provides a 
SabaLog class and for debugging purposes, the BDK pro- 
vides a SabaDebug class. The functionality provided by the 
foregoing classes is similar to that available currently. 

The use of the various classes and interfaces discussed in 60 
this section is described in the "Application Development 
Model" section. 

Services 

A number of services are required by application devel- 
opers to develop robust, flexible, and scalable systems. A 65 
number of these services are provided by the commercially 
available application servers that host the EJB components. 
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In the following paragraphs we discuss the various services 
that an application developer can rely on and how these 
services might be used. 
Distributed Components 

One of the key ingredients for building scalable systems 
is the ability to distribute components. In the EJB model, 
different beans can be deployed on different computers 
transparently. Separation of interfaces from the implemen- 
tation enables automated generation of stubs and skeletons 
that hide the details of network communications. A client 
application (or a bean that relies on another bean) 
(Subsequent references to a client application should be 
interpreted to be inclusive of beans that rely on other beans) 
uses a naming service to first locate the bean and then 
interact with it, thus making no assumptions about location 
of any given component. 

Naming 

As alluded to in* the* previous-paragraph, before using • a • - 
bean, it must first be located. All EJB application servers are 
required to provide Java Naming and Directory Service 
(JNDI) access for bean users. To use JNDI, a client appli- 
cation would typically first get an "initial context" (driven 
by properties such as where to find the EJB server, some- 
what analogous to the JDBC connect string for locating a 
database), and then using the context, look up the home 
interface of the bean by its name. Using the home interface, 
the client can find a specific instance of a bean, create a new 
instance, or remove an instance. The naming service would 
be used and the interaction would be the same even if the 
bean instance is present locally (i.e., exists in the same Java 
Virtual Machine) instead of being deployed on a remote 
machine. 

The JNDI naming mechanism also obviates the need for 
the SabaClassRegistry mechanism that is used at present. 
The client application looks for a bean by a name (say, 
Authentication). Any bean class that provides the implemen- 
tation of the remote and home interfaces can be deployed 
against that name in the application server. Thus, at one 
installation, the default bean class SabaPlatform Login can 
be deployed with a name of Authentication, whereas at some 
other installation, the bean class SabaLDAPLogin can be 
deployed with the same external name to use a different 
authentication logic. 

Persistence 

One of the benefits of using EJBs is that component 
developers do not have to worry about persistence of data, 
as the container hosting the (entity) beans can manage such 
persistence. Automatic persistence service provided by the 
application server enhances the productivity of bean 
developers, is more efficient at runtime, and allows the 
bean's definition to be independent of the type of data store 
used for persistence (e.g., a relational database or an object- 
oriented database). A component developer will be respon- 
sible for declaring part or all of the attributes of an entity 
bean as persistent in its deployment descriptor, and then 
mapping them to fields in a database at deployment time. 
The interface and mechanism of such mapping would 
depend upon the application server being used. 

The bean is automatically saved to the persistent store 
when it is created by a client application using the create( ) 
method, and when lie container decides to synchronize the 
bean's state with the database if the bean's data has been 
changed by the client application. The container's decision 
is based on such factors as transactions, concurrency, and 
resource management. The container will remove the data 
from persistent store when the remove( ) method is called by 
a client on an entity bean. 
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Concurrency should be first developed, retaining a separation between 

A component developer does not have to worry about objects that represent business processes and those that 

concurrent access to an entity bean from multiple tr ansae- represent business data. The two types of objects, obviously, 

tions (such as from several client applications). It is the map t0 session beans and entity beans in EJB parlance. A 

responsibility of the container hosting the bean to ensure 5 controller object, for instance, would indicate a session bean 

synchronization for endty objects In ? ee ^ of * he * ey ' whereas an object that persists its data would indicate an 

word synchronized is prohibited by the EJB Specification. cntity bcan , ^ app ii cation would typ^y ^ inc i udc ui 

p)ncurrent access for session teans ^ not meaningful, smce com po ne nts (such asJSP pages or servlets) which would use 

by definition an instance of a sU eful session bean can be suc^^ 

used by only one client and stateless session beans do not * .. A . K . \ « . , 

maintain any data that needs to be shared. 10 &om an a PP hcat ">° development standpomt: 

Transactions 1- component developer, and 

For transactions, an application developer has two 2. component user, 

options: 1) to explicitly demarcate the boundaries of a It is possible that an individual may play both the roles, 

transaction, or 2) to use declarative transactional manage- Indeed, a component developer may need to rely on another 

ment available with EJBs. Use of declarative transactional 15 component, and thus be a user as well as a developer. We 

management is cleaner and is strongly recommended. In this will first look at the role of a component developer in the 

case, the level of granularity for managing transactions nex t subsection, and then look at the responsibilities of the 

~ ^brreSffcnoVtor methods in a beanr Instead of interleaving component user. ^ Finally; we' w'mlook'at how ^ 

transaction boundaries within business logic, transactional can ^ package d in this alternative embodiment, 

attributes are separately declared in the bean's deployment 20 Component Developer 

descriptor (for a specific method, or as the bean's default) as Xo mM a compon e 0l , a developer needs to perform the 

one of thefollowmgsixopUons:TX_J>fOT_SUPPORTED, following steps 

TX_SUPPORTS, TX_REQUIRED, TX REQUIRES 1 r» « *u ♦ - ♦ ^ t *w 

NEW, TX_MANDATORY, TX__BEA>T1mANAGED^ X ' Define rem ° te mterfaCe ° f ** oom P onent - 

Details of these can be found in books on EJB. 25 2 ' Definc homc mterfacc of the component 

Security 3. Define the bean class. 

As discussed earlier, application developers can use a 4. Create the deployment descriptor of the component, 

stateless session bean, SabaPlatformLogin, to authenticate a As example, one will build a simple SabaPerson 

user. In the deployment descriptor for every bean, access component SabaPerson is a container-managed entity bean 

control entries are defined which list the identities (users or 30 useful for explaining some basic concepts in EJBs and the 

roles) that are allowed to invoke a specific method BDK framework. One then illustrates issues surrounding 

(alternatively, an access control list can act as the default for business logic coding, transactions, and persistence in a 

all the methods in a bean). According to EJB Specification, question-answer format. Note that for simplicity's sake, 

each client application accessing an EJB object must have an package, import, try/catch/finally, etc., statements are not 

associated java .security. Identity object (generally associ- 35 included in the following code segments, 

ated at login time). The general Security system used in the The Remote Interface 
present invention was discussed in more detail above. , 

Read/Write/Arbitrary Privileges 

?f a . rC ^ t . - . , , . , public interface SabaPerson extends ISabaRemotc { 

To locate an instance of an entity bean, each entity bean 40 public string getFuiiNameO throws RMiException; 

provides a method findByPrimaryKey( ) in its home inter- public String getFirstNameO throws RMiException; 

face. In addition, Other finder methods (which must be pvtotic String gctLastNameO throws RMiException; 

named in accordance with the pattern find<criterion>)can ^^jf^ W setFilstNamc C Strin e name ) throws 

also be provided. With container-managed persistence, the wifl sc tUistName(string name) throws RMiException; 

container generates the implementations of such methods 45 } 
automatically at deployment time. The mapping of finder 



methods to the database is vendor-dependent at present. ™ M , ■ , f *j *u l • *u j ^ 

, . j j • j e .i. • / r ^ * I ne remote interface provides the business methods or the 

though a standardized syntax for the same is a goal of EJB i.» • f+u *t u ^ 

j , world s view of the component. In our case, we have a single 

2.0 SpeoficatiOB , effort In toe meanUme a developer can metho(J ^ a ^ J^vc to get the person's full name, 

mplement the , find« r metoods m tenns of findUsingRQU ) 50 ^ ^ ^ ISabaRcmotc ^ d< £ ares aetAa ^ K ) 
andfindUsmgRQLURI( ) methods avauable in SabaEntity- and getAttrVal( } methods for ^^potoiog the attribute 
T ' * n h * values (such as fName and IName declared in the bean 

gging e ugging class), so they don't need to be declared again. 

A component may be used by multiple applications m an Home Interface 

interleaving fashion. 55 

An application could have components distributed over 
multiple computer* — how to assemble a unified log — use a 

"log server" bean — heavy performance price, impacts public interface SabaPersonHomc extends I Saba Home { 
debugging class tOO. public SabaPersonEJB findBy Primary Key(Saba Primary Key id) 

Turning on and off debugging on a component basis. 60 1 ™*f^ n > ^"S^ Ct . IM v 

w , . r , , . A 6 lL . r . t public Collection findByNamcfString fName, String IName) 

Mechanics of how to do it Without having runtime Checks throws FinderException, RMiException; 

every time a method in Debug is called. What if one app public SabaPersonEJB create(String fName, String IName) 

wants a component to turn debugging on whereas another throws CrcatcExccption, RMiException; 

wants to turn it off. | 

Application Development Model 65 

In the alternative embodiment, to develop an application For container-managed beans, the container automatically 

using the BDK, an object model of the application domain provides an implementation of the findByPrimaryKey( ) 
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method and generates the code for other finders (such as 
fiodByName{ )) from an external description, which pending 
EJB 2.0 Specification, is vendor-specific. 
The Bean Class 



public class Saba Person EJB extends Sab a Entity Bean { 
public String id; 
public String fName; 
public String IName; 

public String getFullNameQ throws RMIException 

return (fName + IName); 
public String getFirstNameQ throws RMIException 

return (String) getAttrVal ("fName"); 
public void sctFii3tName(String name) throws RMIException 
setAttrW^fName", name); 

ublic void ejbCreate(String fName, String IName) 

this.id = EDGenerator.getNewIDQ; 
this .fName - fName; 
thisJNamc « IName; 

ublic void ejbPostCreate(String fName, String IName) 

// No action needs to be taken. 



20 



30 



The bean class provides implementations for the business 
methods declared in the remote interface. Mote that the fields 
in the bean class are declared to be public. The EJB 
Specification require this for container-managed persistent 
fields. Furthermore, this is also required by the setAttrVal( ) 
and getAltrVai( ) methods for fields that should be accessible 
via this methods (the methods use reflection to locate the 
fields). The consequences of such visibility are limited, 
however, because the user of a bean only interact with the 
bean through the home and remote interfaces. It is not 
possible for a client to directly assign values to or retrieve 
values from such public fields without going through the 
accessor and mutator methods defined in the remote inter- 
face. 

For each different signature of create( ) method in the 
home interface, corresponding ejbCreate( ) and 
ejbPostCreate( ) methods need to be defined in the bean 
class. Hie code for the bean class is consistent with this 
requirement. 

The Deployment Descriptor 

In EJB Specification vl.l (which can be found at the 
java.sun.com web site), the deployment descriptor is an 
XML file that declares such things as container-managed 
persistent fields and security and transactional characteris- 
tics of the bean and its methods. The following example 
shows part of a deployment descriptor. 



«ntity> 

«description> 

This is part of the deployment descriptor of the 
SabaPcrson entity 
bean. 

</description> 

<*jb-namc>SabaPerson</cjb- oamo 
<iome>coin.saba. examples. SabaPersonHome</home> 
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-continued 



10 



<remote> . . . </remote> 
<ejb-class> . . . <J ejb-class > 
<prim-key-class> . . . </ prim-key-class > 
<persistence-type>Container</persistence-type> 
<xmp-field >id<fanp-fiel d> 
<cmp-field>fName^cmp- field > 
<cmp-ficld>lName</cmp-field> 



<co ntainer-transaction> 

<method> 

<ejb-namc>SabaPei5on<cjb-name> 
<method-name>*</method-name> 

</method> 

<traris-attributc>Supportcd</trans-attributc> 
</container-transaction> 
</entity> 



In EJB Specification 1.0, the deployment descriptor is a 
text file with a somewhat different format. The deployment 
descriptor is generally created using a GUI tool, generally 
supplied by EJB Server vendors. Additional information on 
deployment descriptors can be obtained from EJB literature 
and tool manuals. 

Depending upon the kind of business logic, there are 
different ways of encoding business logic in EJBs. Of 
course, implementation of the methods declared in the 
remote interface of a session bean or an entity bean encodes 
business logic. In addition, EJB provides "hooks" or call- 
back methods for implementing additional types of business 
logic. We have already seen the ejbCreate( ) and 
ejbPostCreate( ) methods that one can use in a manner 
analogous to insert triggers in a relational database. 
Similarly, the method ejbRemove( ) (implemented with an 
empty body in SabaEntityBean and SabaSessionBean) can 
be overridden to encode logic related to deletion of a bean. 
For example, if we wish to encode the logic that if a person 
is removed, all the class registrations for that person should 
also be removed, we can override the ejbRemove( ) method 
within SabaPerson in the following manner. The 
ejbRemove( ) method is called just prior to actual removal 
of the data from the persistent store. 



45 



50 



public void ejbRemoveQ 

{ 

f m Locate the home interface (regnHome) for the 
*• SabaRegistration bean (code not shown) 
V 

Collection regns = (Collection) 
regnHome.fi.ndByPer8onID(this. id); 

Iterator iter - regns. itcratorf); 
while (iter.hasNextO) { 

Saba Registration EJB registra - 

(SabaRegistratio nEJB) 
iter.ncxt(); 
regis trn.removeO; 

} 
} 

Other callback methods are ejbLoadQ, ejbStoreO, 
ejbActivateQ, and ejbPassivate(). 



60 



In the alternative embodiment, transactional integrity can 
be maintained as follows. Consider a session bean which, as 
part of its remote interface, has declared a method 
cancelGass( ) that encapsulates the business process of 
65 canceling a class. As part of class cancellation, we also wish 
to, say, remove the registration records of the persons 
registered for the class. The registration information is 
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maintained by SabaRegistration entity beans. Hence, within 
the implementation of cancelClass( ), besides updating some 
attribute of the SabaClass entity bean to indicate 
cancellation, we would also encode logic for finding the 
SabaRegistration entity beans corresponding to that class 
and then removing them. However, either all these activities 
must succeed atomically, or no change to persistent store 
should be made (i.e., the activities constitute a transaction). 
This would be accomplished by declaring a transactional 
attribute of TX_J*EQUIRED for the method cancelClass( ) 
in the bean's deployment descriptor. If the calling client or 
bean already has a transaction started, the method will then 
be executed within the scope of that transaction; otherwise, 
a new transaction will automatically be started for this 
method. 
How Can 

In an alternative embodiment, complex data types can be 
persisted for container-managed entity beans as follows. 
Suppose there is an entity bean with an attribute that has an 
array of strings as a data type. Since relational databases do 
not support such a data type, one cannot directly map the 
attribute to some column in a database. However, at save 
time, one can potentially convert the array into a single 
String by concatenating the elements within the array and 
using a marker character to delineate various entries. Then, 
at retrieval time, one can look for the marker character and 
reconstitute the array. Entity beans provide two callback 
methods, ejbStore( ) and ejbLoad( ) that can be used for such 
a purpose. SabaEntityBean by default provides empty 
implementations of such methods. An application developer 
can override these methods within the definition of a bean 
and thus persist complex data types. 

In the alternative embodiment, every class in an applica- 
tion does not have to be a bean. Indeed, with the overhead 
of locating a bean through a naming service and going 
through the home and remote interfaces of a bean to perform 
useful work would negatively impact performance (though 
some servers will optimize the process for beans located 
within the same virtual machine). The application develop- 
ers can implement selected classes as helper classes and not 
as beans. Sun Microsystems* J2EE Application Program- 
ming Model identifies certain instances where helper classes 
are applicable. One such example is dependent classes that 
can only be accessed indirectly through other classes 
(beans). Sun's J2EE APM offers CreditCard and Address 
classes as examples of a dependent classes. 

EJBs are packaged as EJB jar files that are comprised of 
the class files for the bean class, the home interface, the 
remote interface, the primary key class (if applicable), in 
addition to the deployment descriptor and a manifest. The jar 
file can be created using the j ar application supplied with 
JDK, or by using some GUI front-end utility provided by the 
J2EE server being used. The deployment mechanism varies 
with the servers. For Weblogic server, an entry can be made 
in the weblogic.properties ' file; for Sun's reference 
implementation, the deploytool utility can be used to 
achieve this in an interactive manner. 

At present, the EJB Specification does not provide a 
mechanism for declaring such constraints, and this would 
have to be achieved programmatically in the create( ) and 
mutator method(s) of the entity beans. 

Component User 

As described above, in the alternative embodiment, a 
partial example of usage of a component was described in 
the context of business logic encoding. This section provides 
a fuller picture of how a component is used in an alternative 
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embodiment, by either another bean or a client application. 
The primary steps in both the cases are the same: 

1. locate the home interface of the bean; 

2. using the home interface, create a new instance or find 
one or more existing instances of the bean; and 

3. invoke the bean's methods to accomplish tasks. 

To locate the bean, JNDI is used. There are some varia- 
tions in how JNDI calls are used with different EJB servers. 
Here we use the getInitialContext( ) method in the 
SabaJ2EEVendor class for locating the SabaRegistration 
bean. 



15 InitialContext ctxt = 

SabaJ2EEVendor.getInitiaIContextO; 

Object objref - ctxtlookup(*'SabaRcgL3tration'*); 
SabaRegistrationHome regaHome » (SabaRegistrationHome) 
PortableRemotebbje^"narrow(bbjW,'''"' 

SabaRegistratioaHome.da5s); 



Once the home interface of the bean is so located, we can 
use it to create new instances of the bean or find existing 
ones. In an earlier example, we had used the home interface 
for finding instances of a bean. Another example, this time 
25 for creating an instance, is presented below 

SabaRegistration regstrn=regnHome.create(personID, 
classID); 

Subsequently, we can invoke business methods of the 
3Q bean simply as follows. 

regstrn.setAttrVal(feePaid, true); 

In addition to the foregoing, additional methods 
(implemented by the bean container) are available for get- 
ting a bean's metadata (from which its primary key class, 

3S remote interface class, etc. can be obtained), comparing two 
beans for identity, etc. Many of these methods are used in 
building tools, such as those for deployment purposes. If 
additional information about these methods is needed, 
please consult the available EJB literature. 

Those skilled in these arts will understand that various 
other alternative embodiments of a business application 
server system and related development kit for developers, 
may be designed around these basic concepts without devi- 
ating from the unique features provided by applicants in this 

„- invention. 

45 

Security System 

In a preferred embodiment of the present invention, the 
Platform's BDK 519 provides an extremely powerful model 
for assigning security; that is, defining the sets of allowed 
50 operations that groups of users can perform. It supports both 
extremely sophisticated definitions of an allowed operation 
and a scalable model for assigning and partitioning security. 
Specifically, the following features are provided: 

Security operations can be specified according to either 
55 the general class of business object or to specific, 
individual business objects. 
Support for both shared security operations (view, update, 
delete, etc) and business-object specific security opera- 
tions. 

60 Security operations can be assigned based on a customi- 
zable partitioning of business objects into domains. 
Security operations can be assigned based on either 
universal or domain-specific user groupings. 
Definitions 

65 The following concepts are central to the Platform's 
Security Model. A Security list Member is any entity that 
can be assigned privileges in the system. Members can be 
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can be individual users of the system (employees or 
customers); they can also be associated with generic roles, 
such as a system administrator, or even an automated 
process, such as an Interconnect ChangeManager. 

A Privilege is a set of one or more possible security 
operations. There are several types of privileges as shown 
below in Table 1: 



,652 B2 

40 

that users who have access to a domain can access objects 
in that domain, and that users who have access to ancestors 
of a given domain also have access to objects in that domain. 

Extensions to the basic domain model may include the 
ability to define multiple, independent domain axes. For 
example, one domain hierarchy might be based on 
geography, another on business function. 



TABLE 1 



Category 
Atomic Privilege 



Component Privilege 



Instance Privilege 



Complex Privilege 



Description 

The most fine-grained form 
of privilege. Defines a 
single type of security 
operation. 

An Atomic Privilege 
applies to a specific 
category of business object 
An Atomic Privilege 
applied to a specific 
business object 
A grouping of one or more 
privileges 



Example 
Create, Delete 



Create Class, 
View Registrations, 
Confirm Internal Order 
View "the Monthly 
Cancellations" Report 

Create, modify, and delete 
classes 



The Platform 501 supports several pre-defined atomic privi- 
leges that apply to all business objects. The pre-defined 
atomic privileges are shown below in Table 2. 

TABLE 2 



Privilege Description 

New Create a new instance of this business 

object 

View View summary or detail information about 

an existing business object 

Edit Change information about an existing 

business object 

Delete Delete an existing business object 

Change Domain Set the domain of an existing business 
object 



Specific categories of business objects can also define 
additional privileges specific to that category. For example, 
the following component privileges only apply to the "Pur- 
chase Order*' business object: 

Change Expiry Date 

Change Initial Credit 

Change Status 

Change Terms 

Domains are the Platform's 501 partitioning mechanism 
for business objects. Domains allow users to define a hier- 
archical structure that models their organization or business, 
for example, based on geography or division. 
For example, the following simple example shows a three- 
domain organization, with a root "World" domain and two 
child "US" and "Europe" domains. 



World 







1 


US 




Europe 



All business objects are assigned a specific domain and 
belong to that domain. In turn, security privileges are 
assigned on specific domains. The domain hierarchy is 
automatically enforced during security checks. This means 



25 Security lists are the mechanism by which members are 
matched with privileges. A Security List defines a set of 
domain-specific privileges and a set of list members. Secu- 
rity Lists are created in a two-step process as follows: 

First, a set of privileges are added to a security list, where 
30 each privilege is applied to a specific domain. A privi- 
lege within a security list — that is, a privilege applied 
to a specific domain — is known as a "granted privi- 
lege." 

3S Second, a set of members are added to a security list. 
Privileges are calculated at runtime based on all the 
security lists a user belongs to. At least one of the lists must 
contain a required privilege in the appropriate domain. This 
combined use of privileges and security lists supports two 

4Q paradigms for administering security across domains: 

1. A centralized approach wherein global administrators 
define security lists that contain a set of (privilege, 
object, domain) triples, that is, one security list can 
apply across different domains. The same global 

45 administrators assign members to security lists. 

2. A decentralized approach wherein global administrators 
define complex privileges that contain a set of 
(privilege, object) pairs with no domain information. 
These serve as "security roles", effectively, global 

50 security lists that are domains-independent. Adminis- 
trators for individual domains then define domain- 
specific security lists containing these privileges. The 
domain administrators assign members in their domain 
to security lists. 
55 The following example shows how privileges work in 
practice. Two security lists are shown below in Table 3 and 
Table 4 containing the following granted privileges: 



65 



TABLE 3 




"Customer" Security List 




Privilege 


Business Object Category 


Domain 


View 


Class 


World 


Create 


Order 


US 
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The API includes: 

TABLE 4 



Privilege 


"US Instructor" Security List 
Business Object Category 


Domain 


"View 


Class 


World 


Create 


Class 


US 


Delete 


Class 


US 


Create 


Conference Room 


US 


View 


Conference Room 


World 


Schedule 


Projector 


US 



For purposes of this example, also assume that the instances 
of business objects shown below in Table 5 exist: 



TABLE 5 



•* Business Object Category 


• Business Object 


Domain ' 


Class 


English 101 


US 


Class 


Spanish 101 


Europe 


Conference Room 


Purple Room 


World 


Conference Room 


Lavender Room 


US 


Projector 


Projector 1520 


Europe 


Projector 


Projector 1120 


US 



If Userl only belongs to "Customer** security list, Userl can 
perform the following operations: 

View Class "English 101" 

View Class "Spanish 101" 

Create a new Order for Class "English 101" 
However, User 1 is not permitted to perform the following 
operations: 

Order the class "Spanish 101" to be taken in Europe 
[because this would require a Order with a domain of 
"Europe"] 

Mew the Purple Room 

Mew the Lavender Room 
If User2 belongs to both the "Customer" and "US Instruc- 
tor" security lists, then User2 can peform the following 
operations: 

View Class "English 101" 

Create a class "English 101" in the "US" domain 

View the Lavender Room 

View the Purple Room 

Schedule Projector 1120 
However, User2 is not permitted to perform the following 
operations: 

Create a new Order for Class "Spanish 101" to be taken 
in Europe 

Create a class "French 101" in the "Europe" domain 
Schedule Projector 1520 

The Persistence Layer of the BDK 519 automatically 
takes account of the predefined atomic privileges (new, 
view, etc) in its behavior. Thus, search results using standard 
finders will only return objects for which a user has view 
privileges, and update operations for which a user does not 
have privileges will automatically throw a Security excep- 
tion. In addition, the BDK 519 provides the ability to 
explicitly query the security model using the API described 
below. 

Security System API 

The BDK 519 provides a Java-based API for managing 
security. As described in the BDK section, this API uses an 
EJB-style session manager named "SabaSessionManageir" 
and a set of helper classes. 



5 1. A set of interfaces representing the basic concepts in the security model. 
// IPrivilege - The base class of privilege. A Privilege is 
anything that can be added to a Security List, 
public interface [Privilege; 

// IA torn ic Privilege - A single allowable operation 
public interface lAtomicPrivilege extends IPrivilege; 
1® // IComponentPrivilege - A single allowable operation on a specific 
object class. 

public interface IComponentPrivilege extends lAtomicPrivilege; 
// ItnstancePriviJege - A single allowable operation on a specific 
object instance. 

public interface IlnstancePrivilege extends IComponentPrivilege; 
// IComptexPrivilege - A structured privilege, capable of grouping 
other 

atomic or complex privileges. 

public interface IComplexPrivikge extends [Privilege, I Han die; 
// Domain - A business object representing an entry in the Domain 
20 hierarchy 

public interface Domain extends [Handle; 

// I Security lis tMember is any interface that can be a member of a 
security list, including IRole, IParty (IPerson or [Organization), 
or I Group 

2^ public interface [Security ListMember extends [Handle; 

/f [SecurityList matches granted privileges to a set of members 
public interface I Security List extends [Handle; 



30 

2. A set of concrete classes capturing the available privileges 
in the system. These classes are application-dependent; 
i.e. there are one set of classes associated with the 
r^arning application built on Platform, another set asso- 
35 ciated with the Performance application, etc. 



For example: 

40 



public class I as tan ce Privileges implements 
IlnstancePrivilege { 

/* Define the set of common atomic privileges that 
apply to all objects in the system. */ 
45 public static final int kEdit « 2; 

public static final int kDelete = 3; 
public static final int kVlew - 6; 

} 

public class ComponentPrivileges implements 
IComponentPrivilege { 

/* Define the set of common atomic privileges that 
50 apply to all components in the system. Notice that 

this class includes all atomic privileges that apply 

to instances */ 

public static final int kNew = 1; 
public static final int kEdit - 2; 
public static final int kDelete - 3; 
55 public static final int kView «■ 6; 

} 

public class PurchaseOrderPrivilcges extends ComponentPrivileges 
{ 

// Privileges specific to the Purchase Order business 
object 

50 public static final int kChangeDomain = 7; 

public static final int kChangeStatus - 11; 
public static final int kChangeTerms » 12; 
public static final int kChangelnitialCredit = 13; 
public static final int kChangeExpiryDate = 14; 
public static final int kChangeCurrency =15; 

65 > 
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2. The interface of the manager used to create and manage 

security lists. -continued 



public interface SabaSecurityManagcr extends I Saba Remote { 
r methods for creating and updating security lists */ 
public tSecurityUst createSecurityList (SecurityDetail detail); 
public SecurityDetail getDctail (ISecurityUst theSecurityList); 
public void update(ISecurityList theSecurityList, 

SecurityDetail detail); 

public void remove(ISecurityUst theSecurityList); 

P methods for adding & removing privileges to security lists 

V 

public void addPrivilegeflSecurityList thelist, IPrivilege 
thePrivilege, Domain theDomain); 

public void removePriviJege(I Security List theList, IPrivilege 
thePrivilege, Domain theDomain); 

r methods far adding & removing members from security lists */ 

public void addMember(ISecurityList thelist, 
ISecurityListMember theMember); _ . „.;.,„...,., 

public void removeMcmber(ISecuritylist thelist, 
ISecurityListMember theMember); 

/* methods to check privileges •/ 

public boolean isMember(ISccuritylist thelist, 
ISecurityListMember theMember); 

public boolean hasPrivilege (ISecurityListMember theMember, 
IAtomicPrivilege thePrivilege, Domain theDomain); 

public Collection getPrivileges (ISecurityListMember theMember, 
I Component theComponent, Domain theDomain); 
/* standard finder */ 

public ISecurityUst find Security listByKe y(String id); 

public Collection findSecurityListByName(String name); 

public Collection findAllSecurityListsQ; 
} /• SabaSecurityManagcr */ 



10 



15 



The following code fragment demonstrates how the Security 
API can be used to create a new security list, assign users to 
that security list, and check privileges for that user. Note that 
this code example uses several other session bean managers, 
such as a DomainManager and PartyManager, provided as 
part of Platform. 



/* Step 4: check a user's privileges V 

IPrivilege editClassPriv => (IPrivilege) new 

CtomponentPrivfleges(CbmponentPrivUegesJcEdit, 
classesCo mponent); 

boolean can EditCl asses - 
theSecurity Manager. hasPrivilege(member, 
editOassPriv, domain); 



Best Mode 



In a preferred embodiment, the Platform's BDK security 
API focuses on the database structures and SQL used to 
20 store and query security information. It also touches on the 
algorithms used in implementing the Java API. 

Information related to security is stored database tables as 
25 shown below. The Platform's BDK Security System uses 
Java code to read and write values to these database tables. 



fgt_domain stores all domains as shown below in Table 6. 
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TABLE 6 



Column Name type 



Required? Description 



35 



id 

description 

name 
Parent Id 



OBJECTID 
varchar (255) 

varchar (25) 
OBJECTID 



y 

N 



Long descriptive string 
for the domain. 
Name of the domain 
ID of the parent domain 



'/ m Step 1: create a security list V 
String privName - "Gues^'; 
String priv Description <= "Guest login and access"; 
Domain domain = 

theDomainManagerfindDomainB yKey 
("domiiiOOOOOOOOOOOlOOO'O; 

String domain ID = domain.getId(^ 
SecurityDetail theDetail - 

new SecurityDetail (privName, privDescription, 
domainID); 

IsecurityList securityList - 

theSecurityManager.createSecurir^List(theDetail); 
r Step 2: grant privileges by adding them to the list */ 
IComponent classes Component - 

thcComponentManager.getCompoacnt( u c]as3C3"); 
r create atomic privileges and add them 7 
IPrivilege viewClasses - (IPrivilege) 

new CbniponcntPriv3eges(CtomponcntPrivilegesJtVicw, 
classesComponent); 

theSecurityManagetaddPrivilege(securityList, 
viewClasses, domain); 

IComponent groupCo mponent = 

theCornponentManager.get Component ("Product Group"); 
IPrivilege viewGroups - (IPrivilege) 

new componentPrivDeges(ComponentPrivilegesiView, 
classesComponent); 

theSecurityManagenadaTrivUege(securityList, viewGroups, 

domain); 

I* Step 3: assign a member to the security list 7 
ISecurityListMember member - (ISecurityListMember) 
thePartyManager-findEmployecByKcy 
("emploOOOOOOOOOOOlOOO"); 

theSecurityMaoagcnaddMember (SecurityList, member); 



fgt ss privs stores all atomic privileges as shown below in 
Table 7a. 



TABLE 7a 



45 



50 



55 



Column Name 


type 


Required? 


Description 


id 


OBJECTID 


y 




object_type 


OBJECTID 


Y 


object Id (data dictionary 
class id) to which the 
privilege applies. 


priv_name 


varchar (SO) 


Y 


a description string for 
the privilege. 


priv^seq 


INT 


y 


a number which 
identifies the 
type of privilege. 

1 => New 

2 -> Edit 

3 -> Delete 

4 => Save 
etc. 

Note: 1-5 common to all 
classes 11 onwards — 
class specific. 



60 



For example, in Table 7b below, the following data captures 
the available privileges for the Purchase Order business 
ss object. Notice that the values in the priv_seq column 
directly correspond to the constants defined by PurchaseOr- 
derPrivileges class defined in the Java API. 
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TABLE 7b 

objcct_typc priv__name priv_scq 



5sprv000000000001008 


pycatOOO0O00OO00a036 


New 




1 


ssprv000000000002008 


pycatOOO 000000001036 


Edit 




2 


ssprv000000000003009 


pycat000000000001036 


Delete 




3 


ssprv000000000010175 


pycat0OO00OO00001036 


View 




6 


ssprvOO 0000 00 0010224 


pycatOOOOOOOO 0003036 


Change 


Domain 


7 


ssprv000000000007120 


pycat000000000001036 


Change 


Status 


11 


ssprv000000000007121 


pycat000000000001036 


Change 


Terms 


12 


ssprv000000000007122 


pycatOOO 000000001036 


Change 


Initial Credit 


13 


ssprv000000000007123 


pycatOOQOOOOO 0001036 


Change 


Expiry Date 


14 



15 

fgt list stores all security lists as shown below in Table 8a. 



TABLE 8a 



Column Name 


type 


Required? 


Description 


id 


OBJECTED 


Y 




description 


varchar (255) 


N 


Description of this list 


name 


varchar (25) 


Y 


Name of the list 


owner_id 


OBJECTTD 


N 


The owning object 








of this list if any 


security 


BOOLEAN 


Y 


0 = Not a security list, 








1 " Security List 



For example, in Table 8b below, the following data defines 
a security list to capture generic user privilges: 

TABLE 8b 

id name description security 

lis taCWOO 00 000002003 User A generic law-privileged user 1 



Column Name 


Type 


Rq? 


Description 


id 


OBJECTID 


y 




granted_on_id 


OBJECTID 


y 


Foreign key to the business 
object class or instance on 
which this privilege is granted. 


granted_to„id 


OBJECTID 


y 


Foreign key to the security list 
on which this privilege is 
granted. 


privs 


varchar (50) 


y 


50 character bitmap containing 
the granted privileges. 


domain_id 


OBJECTID 


N 


Foreign key to the domain on 
which this privilege is granted. 



Notice that this schema shown in Table 10 stores all atomic 
privileges on a (object, domain, list) triple in a single row by 
appending the integer keys of the atomic privilges into a 
single string. Notice also that the schema shown in Table 10 
can capture both: 



25 
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fgt_list_entry stores all members of a security list as shown 
below in Table 9. 



TABLE 9 



Column Name 


type 


Rq? Description 


id 


OBJECTID 


Y 


list id 


OBJECTID 


Y Foreign key to a security list 


person_id 


OBJECTID 


Y Foreign key to a list member. 






The object ID may be a 






person, role, or group. 



fgt_ss__grants stores all granted privileges as shown below 
in Table 10. 
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1) privileges on business object classes, by storing the 
data dictionary primary key of the class in the granted__ 
on_id column. 

4S 2) privileges on business object instances, by storing the 
object id of the instance in the granted_on_id column. 

For example, the following row from Table 10 describes a 
5Q grant that allows members of the "Users" security list to 
create and view orders, but not edit or delete them. The 
"ddcls" prefix (for "data dictionary class") on the granted__ 
on_id value indicates that this OBJECTID refers to a 
business object class. The 1" and 6* bits of the privs flag are 
on, providing create and view privileges only. 



id granted_on id 


granted_to_id 


ssgrn000000000001264 ddcls000000000001055 


lista0OO0O00000O2003 


privs 


domain id 


10000100000()0000(XXXXJOOOOOOOOOa)OOOOOOOOOM 


dorninOOOOOOOOOOOOOOl 
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The following row from Table 10 describes a grant that 

allows the same list to execute a specific report. The "reprt" -continued 

(for "report") prefix on the granted_on_Jd value indicates 

that this OBJECT1D refers to a Specific instance of the | | to_char(decode(sum(to^umber(substr(s.privs, 5, 1))),0,0,1)) 

Report business Object. The ll* bit of the privs flag is on, j ( to_chaT(decode(sum(to_Biunbcr(substr(s.privs, 6, 1))),0,0,1)) 

meaning the grant gives Execute privileges only. 



id granted on_id 


granted_to_jd 


ssgrn000000000202056 rep rtOOOOOOOO 000 1000 


lista000000000002003 


privs 


domain_Jd 


0000000000 10CWOOOOOOOCK)CK)000000000(XXXX)0(XXKK)00000 


dominOOOOOOOOOOOOOOl 



The Platform's BDK Security System also utilizes an 
addPrivilege( ) method. The addprivilege( ) method has 
different logic depending on whether a row already exists in 
fgt_ss_grants for the combination of security list, business 
object, and domain. If a row exists, it retrieves the existing 
row, sets the additional bits defined by the IPrivilege 
parameter, then updates the row. If no row exists, it creates 
a empty privilege bitmap, sets the bits defined by the 
IPrivilege parameter, then inserts a row. 

The Platform's BDK Security System also utilizes an 
hasPrivilege( ) method. The addprivilege( ) method executes 
a SQL query to return all privilege bitmaps for each security 
list the user belongs to that match the target object and 
domain parameters. It iterates through each bitmap and 
returns true if the privilege has been set in any one. The SQL 
query that is executed is: 



/* select all of a user's grants on an class in a given domain, 
parameter 1 - person id 
parameter 2 - class id 
parameter 3 = domain id */ 

select g.id, g, privs from fgt_ss_grants g, fgt_Iist 1, 
fgt_Jist_entry e where e.person_id - @@001 and e.Ust_Jd - l.id 
and l^ccurity = 1 and 

g.granted_to_id = lid and g.gianted_on_Jd = @@002 and 
g.domain id - 



-continued 
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The BDK Persistence layer also contains code that directly 
accesses, these database tables to check security privileges. 
A utility class, SabaPrivileges, contains a hasprivso method 
that is called at predefined points by the SabaObject and 
SabaEntityBean implementations, including whenever 
objects are saved and restored. This method has the follow- 
ing signature: 

public boolean hasPrivs(String objectID, String classID, 
String domain ID, int privToCheck, boolean anydomain) 
SabaPrivileges contains a Java hashtable that caches 
privilege for each business object in the system. The 
hasPrivs( ) method iterates through these privileges to look 
for a match, using logic similar to the 
SabaSecurityManager.hasPrivilege( ) method. 

If the cache is empty, SabaPrivileges queries the database 
to load the appropriate privileges. The SQL used is the 
following: 



select s.granted_on_jd granted_on, substi( 

to_char(decode(sum(lo_number(substr(s. privs, 1, 1))),0,0,1)) 
| j to_char(decode(sum(to_number(substr(s.privs, 2, l))),0j0,l)) 
| | to_char(dccodeCsum(to_number(substr(s.privs, 3, l))) t 0^),l)) 
j ] to_char(decode(sum(to_iiumber(substr(s.privs, 4, 1))),0,0,1)) 
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to_cnar(decode(sum(to_number(substr(s.privs, 7, 1))),0,0,1)) 
to_chai(decode(siim(to_number(substr(s.privB, 8, 1))),0,0,1)) 
to - _cnar(decode(sum(to_number(substr(s.privs, 9, 1))),0,0,1)) 
to_chai(decode(sum(to_number(substr(s.privs, 10, 1))),0,0,3)) 
to_chai(decode(sum(to_number(substr(s.privs, 11, 1))),0,0,1)) 
to_char(decode(sum(to_numbcr(substr(s.privs, 12, 1))),0,0,1)) 
to_char(decode(sum(to L_number(substr(s.privs, 13, 1))),0,0,1)) 
to_chai(decode(sum(to_nnmber(substr(s.privs ) 14, 1))),0,O,1)) 
to_char(dccode(siim(to_jiumber(substr(s.privs, 15, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(s.privs, 16, 1))),0,0,1)) 
to_cbar(dec^e(sum(to_number(substr(s.privs, 17, 1))),0,0,1)) 
to_char(decodc(sum(to_number(substr(s.privs > 18, 1))),0,0,3)) 
to_char(decode(sum(to_number(substr(s.privs, 19, 1))),0,0,1)) 
to_cbar(decode(sum(to - jiumber(substr(s.privs, 20, 1))),0,0,1)) 
to_chai(dc«»deCsum(to_numbcr(substr(s.priv5, 21, 1))),0,0,1)) 
to_char(decode(sxim(to__number(substr(s.privs, 22, 1))) ,0,0,1)) 
to_char(decode(sum(to_number(substr(s.privs, 23, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(s.privs, 24, 1))),0,0,1)) 
Uj_cbai(decode(sum(to__number(substr(s.privs. 25, l))),0,O,l)) 
to_char(decode(sum(to_number(substr(s.privs, 26, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(s.privs, 27, 1))),0,0,1)) 
to_chai(decode(sum(to_number(substr(s.privs, 28, 1))),0,0,1)) 
to_chai(decode(siim(to_number(substr(s.privs, 29, 1))),0,0,1)) 
to_char(decode(simi(to^umber(substr(s.privs, 30, 1))),0,0,1)) 
to_char(dccode(sum(to__number(substr(s.privs > 31, 1))),0,0,J)) 
to_char(decode(sum(to_number(substr(s.privs, 32, 1))),0,0,1)) 
to_char(decode(sxim(to_number(substr(s.privs, 33, l)fl,0,0,l)) 
to_cbar(decode(sumCto_number(substr(s.priv5, 34, 1))),0,0,3)) 
to_c^(decc<k(sum(to_^umber(substr(s.privs, 35, 1))),0,0,3)) 
to_char(decode(sum(to_nximber(substr(8.privs, 36, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(s.priv5, 37, 1))),0,0,3)) 
to_char(decode(sum(to_number(substr(s. privs, 38, 1))),0,0,1)) 
to_cnar(decode(sum(to_number(substr(B.privs, 39, 1))),0,0,3)) 
to_char(decode(sum(to_jiumber(substr(s.privs, 40, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(s.privs, 41, 1))),0,0,1)) 
to_char(deoxle(sum(tD_number(substr(s.privs, 42, 1))),0,0,1)) 
to_char(decode(sum(to_jiumber(substr(s.privs, 43, 1))),0,0,1)) 
to_cbai(decode(sum(to_number(substr(s.privs, 44, 1))),0,0,1)) 
to_chai(decode(sum(to_number(substr(s.privs > 45, 1))),0,0,1)) 
to_chai(decode(5Um(to_number(substr(s.privs, 46, 1))),0,0,1)) 
to_char(decode(siim(to_number(substr(s.privs, 47, 1))),0,0,1)) 
to_char(decode(sum(to_number(substr(s.priv8, 48, 1))),0,0,1)) 
to_char(decode(sum(to_numbcr(substr(s.privs ) 49, 1))),0,0,1)) 
j U)_cbAi(d^ecode(sTim(to_nuiriber(substr(s.privs, 50, 1))),0,0,1)), 
, 50) privs, tnode_id domain_id from fgt_ss_grants s, 

fgt_lLSt_entry 1, tpt_dummy_flat_tree t where 1. person id - @001 

and s.granted^on_id - @003 and I. list id » s.granted_to_Jd and 
s.domain_id ** trelated_to and (l.group_label is null or 
Lgroup_label - @002) group by s.granted_on_id, t.node_id 



60 

The SQL used in this query has two unique features: 
It uses a table called tpt_dummy_flat__tree that stores the 
parent/child relationships for all domains in the system. 
This allows it to include a join that obtains privileges 
65 for both the specified domain and all its parents. 

It checks the value of the privs field bit by bit, and 
concatenates the results together to form a new bitmap 
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that is the union of the bitmap fields for the specified 

domain and all its ancestors. 
The following example data in tpt_dummy_flat_tree 
shown in Table 11 defines the relationships between three 
domains, where dominOOOOOOOOOOOOOOl is the top-level 
parent, dominOOOOOOOOOOOlOOO is its child, and 
dominOOOOOOOOOOOlOOl is its grandchild. 



TABLE 11 


NODE_JD 


RELATED_TO 


R 


REL_LEVEL 


dominOOOOOOOOOOOOOOl 


dominOOOOOOOOOOOOOOl 


I 


1 


dominOOOOOOOOOOOlOOO 


dominOOOOOOOOOOOOOOl 


A 


2 


dominOOOOOOOOOOOlOOO 


dominOOOOOOOOOOOlOOO 


I 


1 


dominOOOOOOOOOOOlOOl 


dominOOOOOOOOOOOOOOl 


A 


3 


dominOOOOOOOOOOOlOOl 


dominOOOOOOOOOOOlOOO 


A 


2 


dominOOOOOOOOOOOlOOl 


dominOOOOOOOOOOOlOOl 


I 


1 



WDK Server 

The Web Content Server 800 enables the present inven- 
tion to interact with users regardless of the users hardware 
platforms, locations, and software systems. The Web Con- 
tent Server 800 allows the present invention to overcome the 
difficulties of prior art systems associated with having an 
infrastructure which is tightly coupled to application 
products, specific hardware platforms and specific Operating 
systems and related services. 

The Web Content Server 800 can allow the present 
invention to interface with many other industry standard 
software programs to make the exchange and flow of data 
easy and accurate, and enables interconnection with external 
systems, special networks, like SabaNet, and the Internet. 

The Web Content Server 800 is web-enabled and provides 
a unified set of interfaces for interacting with web based 
users as well as other users. 

The Web Content Server 800 can also allow vendors/ 
developers to develop applications on the Platform, make 
use of core, technology for information matching and 
distribution, and provide standardized access to connectivity 
with other systems and platforms in a users network 

As shown in FIG. 8A, one embodiment of an Web 
Content Server 800 provides an interface between users 802, 
804, and 806 and the Platform. The Web Content Server 800 
preferably includes an engine 808, style sheet control system 
810 for various user display protocols, a JAVA virtual 
Machine 812 and the related runtime support. 

The Style Sheet Control System 810 contains mecha- 
nisms to manipulate various kinds of display style sheets, to 
generate and execute web links, to manage dynamic content 
generation and dynamic generation of Javascript. The Style 
Sheet Control System 810 also can allow vendors/ 
developers to modify, add, or delete the mechanisms in the 
Style Sheet Control System 810. Thus, vendors/developers 
can customize the presentation of data to the users. 
User Generation of Web Content 

Web Content Server 800 can also provide the platform's 
web content generation engine for use by users to create, 
render, and present web content while improving the 
dynamic acquisition of data from a variety of sources 
followed by its reformatting and display via style sheets. 
Using web standards for XML and XSL, Web Content 
Server 800 provides a user with a customizable framework 
for decoupling data from presentation, and generating web 
content in a- variety of formats, from standard HTML to 
WML. 

The Web Content Server 800 provides a "page engine" 
808 which allows users (such as developers, consultants and 
customers) to build web content using a separation between 
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Model, Widget, and View instructions. The engine 808 
separates data production, interaction elements and display 
information, and maintains these aspect of page production 
in different files. 

5 The engine 808 supports three components: (a) Widgets, 
which are reusable interactive components such as buttons 
and data entry fields; (b) Models, which encompass the data 
and user operations used by the application (Data can be 
simple Strings or complex objects); and (c) Views, which 

10 use style sheets to define and control the presentation of 
output to the user. 

Using the system 808 provides, among other things, the 
following advantages for a user: 

Improve maintainability of web content. 

1S Partition web content development between users (such as 
component developers, Java developers, and UI 
developers). _ 
Provide easy and extensive customizability by users. 

20 Improve productivity of building web content. 

Provide improved authoring and debugging support. 
Provide the infrastructure for targeting alternate deploy- 
ment platforms (ie palmtops). 
In one embodiment, the engine 808 uses XML, XSLT 

25 (extensible Stylesheet Language Transformations), and RDF 
(Resource Description Framework), built round a publishing 
framework called Cocoon to enable the functionality of Web 
Content Server 800. 
The engine 808, in conjunction with a set of tools, 

30 utilities, APIs, and predefined widgets and views, acts as a 
platform and provides the user with a set of tools, tag and 
widget libraries, Java classes, and XSL style sheets. Tools 
included with the platform 808 help users perform the 
following activities: (a) Authoring — users need to create and 

35 maintain control files, model files, widget files, and view 
files; (b) Debugging — the process starting with obtaining 
data and ending with viewing is involved so having tools or 
methods for debugging problems is essential; and (c) 
Customization — customizing the final product can certainly 

40 be accomplished with the tools used for authoring and 
debugging, but additional tools can radically simplify tasks 
like product upgrades or performing simple customizations. 

The platform 808 allows content, logic and style to be 
separated out into different XML files, and uses XSL trans- 

45 formation capabilities to merge them resulting in the auto- 
matic creation of HTML through the processing of statically 
or dynamically generated XML files. The platform 808 can 
also generate other, non-HTML based forms of XML 
content, such as XSL:FO rendering to PDF files, client- 

50 dependent transformations such as WML-formatting for 
WAP-enabled devices, or direct XML serving to XML and 
XSL aware clients. 

The platform 808 divides the development of web content 
into three separate levels: (a) XML creation — The XML file 

55 is created by the content owners. They do not require 
specific knowledge on how the XML content is further 
processed — they only need to know about the particular 
chosen "DTD" or tagset for their stage in the process. This 
layer can be performed by users directly, through normal 

60 editors or XML-aware tools/editors; (b) XML processing — 
The requested XML file is processed and the logic contained 
in its logicsheet is applied. Unlike other dynamic content 
generators, the logic is separated from the content file; and 
(c) XSL rendering — The created document is then rendered 

65 by applying an XSL stylesheet to it and formatting it to the 
specified resource type (HTML, PDF, XML, WML, 
XHTML, etc.). 



04/06/2004, EAST Version: 1.4.1 



US 6,6 

51 

Dynamic Web Content Development Using Web Content 
Server 800 

The Web Content Server 800 can be based on XML, 
XSLT and Java technologies. Using these technologies, the 
Web Content Server 800 allows for easier user interface 5 
customization, more flexibility in page functionality, easier 
page maintenance and the creation of more easily reusable 
code. It encourages the separation of data production, inter- 
action elements and display information by separating dif- 
ferent aspect of page production in different files. 10 

Using platform 808, developing a web page (web content) 
requires the development of the following components: (a) 
a control file; (b) a model file; (c) a view file; and (d) 
Command Managers and Commands. 

The Model contains all the data and interactivity for a is 
given page. Users are responsible for generating an XML 
page containing the raw data they wish to display, indepen- 
dent of the appearance of that data or any additional pre- 
sentation information. 

The Model can be implemented using a dynamic page 20 
engine (JSPs or XSPs). In addition, API 808 provides a 
variety of helper tagsets to automate common scripting 
operations, minimizing the amount of custom scripting 
required by a user. 

Model Developers are typically Java programmers, since 25 
the bulk of development effort is implementing a companion 
Java Bean that invokes the appropriate SABA Manager API. 
They then use the dynamic features of the engine (tag 
libraries and Java scripts) to place data from the bean onto 
the page. 30 

The 'View contains all style and presentation for a given 
page. Users are responsible for implementing an XSLT 
stylesheet that transforms the model into a specific presen- 
tation environment. Mew developers are typically UI 
designers, since the bulk of authoring effort is crafting the 35 
HTML for a static page, then adding in the set of XSLT tags 
to create a stylesheet for the associated model page. 

Widgets are a set of predefined UI components and 
presentation elements common to web applications. Widgets 
can have user interactivity (fields, finks) or be presentation 40 
only (images). Widgets can be implemented as XSLT 
stylesheets. The platform 808 includes a predefined set of 
common widgets that can be used by both model and view 
developers. Note also that developers have the option of 
overriding the default widgets to provide enhanced or cus- 45 
torn functionality if required. 

The important distinction between tag libraries and wid- 
gets is that tag libraries are used in the model and are an aid 
to dynamic content generation, whereas widgets are used in 
the transform step and are an aid to end-content generation. 50 
Tag libraries can be implemented in Java, whereas widgets 
are preferably implemented as stylesheets. 

FIG. 8B shows how the engine 808 processes/uses these 
files to produce dynamic web content. 

The process of creating the HTML to send to the browser 55 
begins with reading the control file, 860. The control file 862 
is simply a file that identifies the model file 864, the view file 
866 and the widget library 868 to use to produce the final 
HTML result 870. The control file 862 also contains link 
transformation information that is used to transform links 60 
used in the model file 864. This link transformation is used 
to map model-file hyperlink references contained in the 
model file 864 to appropriate control file names. 

The model file 864 is loaded and preprocessed based on 
the information contained in the control file 862. The 65 
preprocessed model file is executed in three steps. In 872, 
any tags from the tag library are processed. The tag library 
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includes tags for internationalization, command invocation 
and widget management. In 874, the resulting XML file is 
then further processed to generate a Java class. In 876, the 
Java class is executed to produce the model instance 878. 
The model instance 878 contains all data and other infor- 
mation needed for display. For example, the model instance 
878 will contain the XML form of the data retrieved by the 
Commands invoked in the model page and it will contain all 
internationalized labels and widgets. In 880, the model 
instance 878 is first transformed using the widget library 
868. In 882, the result of the widget transformation is then 
further transformed using the view transformation file 866 to 
produce the final result 870. 

The process outlined above also highlights how the dif- 
ferent aspects of developing dynamic web content are, sepa- 
rated. The design of a particular web page is the result of 
answering the following questions: (a) What do I do with 
parameters sent from the browser and what data is needed to 
display the page? How do I perform "these tasks? (b) How " 
will the user interact with the page? What buttons, entry 
fields etc. will the user have? and (c) How are the data and 
the interaction elements displayed on the page? 

The answer to question (a) results in the model page and 
the Command objects used by the model page. The model 
page invokes all needed Commands to perform the tasks of 
the page and to produce the data needed for display. The 
answer to question (b) produces a listing of all widgets and 
their linkages to the data being displayed. Although this list 
is part of the model page, the list of widgets and then- 
linkages are all declared in a clearly identifiable part of the 
page. Finally, the answer to question (c) produces the view 
transformation page. 
Page Development Process 

Typically the page development process starts with an 
HTML mockup of the page. The Web Content Server 800 
development process can start with the HTML mockup as 
well. However, users do not modify this mockup to include 
code. Instead the process illustrated in FIG. 8C is followed. 

As illustrated in FIG. 8C, using the HTML mockup 884, 
the user develops three specifications. The data model 
specification 886 is developed to meet three basic criteria. 
First, the data model needs to contain enough information to 
drive the interface. For example, if the interface needs to 
display the name of an object, then the data model must 
contain the object name in some form. Second, the data 
model specification should maximize reuse of command 
objects. For example, if a command object already exists 
that can retrieve a needed object in a serialized XML format, 
then the data model of the command object should be reused 
instead of reinventing a new XML representation of the 
same object. Finally, the data model specification should be 
generic so other pages can reuse the model generation 
components (Commands). How general the data model 
should be is determined by balancing the trade-off between 
performance (since producing more data may incur perfor- 
mance penalty) and reusability. If producing a more general 
data model causes high performance penalty, then a less 
general solution may be better. On the other hand, if adding 
a few not needed items comes at no or little performance 
cost, then the more general data model is preferred. For 
example, objects implementing the DCMLObject interface 
will typically provide more than enough information about 
themselves. The data model specification 886 should essen- 
tially be a sample of the data returned by the Command 
objects and the specification XML should be wrapped in 
tags. 

The widget specification 888 is a list of widgets needed by 
the page. These widgets include input fields of all types 
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(textboxes, radio button collections, check box collections, example, the model for a page that needs to display the 

dropdown lists, hyperlink buttons, etc.). Besides declaring parents of a particular security domain only may also 

what widgets the page needs, the specification 888 can also produce other information about the security domain (e.g., 

include how these widgets relate to the data model. For the description of the domain). This is especially likely when 

example, the page may require an edit button widget for 5 the model page reuses other, already existing command 

every object it displays. The widget specification 888 can objects. In such cases displaying additional content can 

therefore indicate that the edit button is "attached to" those simply be done at the view page level: the user needs to 

objects. The widget specification 888 can be very place the newly required information somewhere on the 

incomplete, because users (such as view developers) will view page. Removing information items is also very simple, 

typically only need the name of the widget for layout 10 since users can simply delete a particular HTML/XML 

purposes. The widget library will take care of rendering the fragment if viewing that piece of the model is not needed, 

widget itself. Changing Look and Feel of Widgets Globally 

Hie third specification is the specification of internation- The use of widget libraries make it very simple to change 

alized items 890 (labels, graphics). The specification 890 the look and feel of widgets across pages. Either the widget 

includes a list of all labels and images used on the page. The 15 transformation of the used widget library can be changed or . 

specification 890 contains just the name of the label and an alternative widget library can be developed. In the latter 

some sample text for the label. case control pages must be updated to point to the new 

Once the specifications 886, 888, and 890 are complete, • instead of the original widget library;**" 

the user or a tool, produces a sample model instance 892. Adding New Interaction Components 
The user can use the model instance 892 to test the view 20 If the guidelines for model page design are followed then 

stylesheet (by using any standard XSLT tool). The user adding new interaction components (e.g., buttons) is a very 

develops the view stylesheet by converting the original simple task. Adding a new widget (e.g., Cancel button) 

HTML mockup to an XSLT stylesheet to retrieve dynamic means adding a new widget to the widget section of the 

data, widgets and internationalized labels from the model model page AND changing the view page to include the new 

instance. This conversion process can mostly be done in an 25 widget. Since the widget section is a separate section of the 

HTML editor. model page, software engineers (and perhaps UI engineers) 

Customizing/Modifying a Page can make the required change without disturbing/interfering 

One of the benefits of using the platform 808 for page with any other part of the model page, 

development is in the ease of page customization and page Components of the Platform 808 

modification. Often the look and feel of pages needs to be 30 The control page associates a particular model page, view 

modified after the initial design. Using conventional systems page and widget library. 

this process was very painful: individual pages had to be The model page produces the data needed for displaying 

revisited by software engineers and tweaked to confirm to the page and it also defines the widgets (interaction 

the new requirements. These new requirements often meant elements, such as links, buttons, input fields, etc.) and 

changed look of textual/graphical information (e.g., justifi- 35 internationalized resources (labels, graphics) used by the 

cation of text, font, color), changing the layout (e.g., adding view page. The model page has a well defined structure, 

another Save button to the bottom of the page, moving Model pages can produce XML representation of data using 

buttons and table columns around), or adding/removing command managers and command objects. A model page 

information content (e.g., display the price of an offering but can invoke a command using a tag. After the model page is 

don't display the description of the offering). Also, often 40 executed, the tag will be replaced with the XML data 

changes are required across pages: e.g., we want every link produced by the selected Command, 
button to use "Helvetica" instead of "Verdana" for its label, The model instance is the XML document produced by 

and the alt label for the link image should be the same as the executing the model page. 

label of the link itself. Sometimes page changes include The view page displays the data and widgets contained in 

adding new interaction components, e.g. adding a "Cancel" 45 the model instance (i.e. the XML document produced by 

button to the page, or adding an edit button next to each executing the model page). If the control page declares a 

displayed object. Such changes are much simpler to perform widget library to use, then the view transformation takes 

using Web Content Server 800. place after the widgets have already been transformed to the 

Modifying Text/Graphics Look and Feel appropriate format (e.g. HTML), 

To change the look and feel of textual and graphical 50 The widget library contains the display transformation for 

information, the user can edit the view page in an HTML widget components. After the model page executes the 

tool. The user can add <span>, <div> etc. tags around the produced widgets are transformed to the appropriate output 

components needed modification, and define the "style" format (e.g., HTML). The resulting HTML markup is 

attribute to reflect the desired look and feel changes. If the wrapped in tags so the view transformation page can easily 

user needs to develop for browsers with limited CSS support 55 identify and place each widget. 

(e.g., Netscape 4.x), the user can wrap the components in The tag library contains tags users can use in their model 

<u>, <b>, <font>, etc. tags as needed. pages to access common code functionality. This common 

Layout Changes functionality includes accessing resource bundles, retrieving 

The cut/copy/paste commands of the HTML editor can be page parameters, executing commands, declaring widgets, 

used to perform most layout changes requiring the reposi- 60 etc. 
tioning of different components. Dreamweaver, for example, Control Page 

gives users powerful HTML/XML element selection capa- The entry point into any platform 808 page is an XML 

bilities that make it easier to move and copy whole HTML/ document that serves as a controller. This page is simply an < 

XML document fragments. XML document that points to the model, view, and widget 

Adding/Removing Information Content 65 documents. This convention creates a clean decoupling 

Often the model specification will result in the production between the three constituent pages. As an example of the 

of more content than needed by a particular view. For benefit of this approach, web content administrators may 
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substitute a different control page in a deployment environ- 
ment; this allows them to use the same model while modi- 
fying just the view. 
Coding Guidelines 

Pages built using the platform 808 employ certain con- 5 
ventions and coding guidelines to ensure consistent opera- 
tion and simplify some processing steps. These coding 
guidelines include the following: 

a. head Element 

All model pages must contain a head page element that 1Q 
defines some information specific to the model. It is used to 
capture the following: 

required metadata about input and pass-through param- 
eters 

values of il8n labels. The convention is that all il8n 
values are obtained via the il8n utility tag in the model 
page; this information is then passed on to the 

stylesheet in. a,predetermined ^location within the wdk- 

:head element 

page title and other useful information about the page. 2 o 

b. Widget Stylesheet 

The widget stylesheet is simply a list of xsl includes of the 
widgets used on this page. The widgets can be from the set 
of predefined widgets or can be customized widgets. 
One Example of a Preferred Embodiment 25 

In one preferred embodiment, the Web Content Server 
800 is a dynamic content generation framework based on the 
apache Cocoon project. Like other approaches, such as JSP, 
ASP, ColdFusion etc., the Web Content Server 800 would 
allow developers to create web pages to display data derived 30 
dynamically through some business logic. Unlike other 
dynamic content generation frameworks, the Web Content 
Server 800 separates the content from its presentation. This 
separation makes it easier to customize pages, to provide 
different versions of pages to different user agents (desktop 35 
browsers, handheld devices, etc.). 

Content production and presentation separation is 
achieved by following a Model-View- Widget (MVW) para- 
digm. In this paradigm three distinct components are respon- 
sible for generating the final output sent to the client ^ 
(desktop browser, WAP phone, handheld device). The model 
page is responsible for producing the content as well as the 
user interaction components (widgets). Widget look and 
behaviors are added during the widget transformation. 
Finally the View transformation provides the look and 4S 
layout for the content and widgets produced by the model 
page. 

File Loading Algorithm 

When the Cocoon engine processes the HTTP request, it 
invokes the getDocument( ) method of the file producer 50 
registered with Cocoon. Web Content Server 800 uses a 
specific file producer (SabaProducerFromFile) to load the 
requested file. This file producer uses SabaSite properties to 
determine the location of the requested file. To register the 
Web Content Server 800 specific file producer, the following 5S 
line is added to cocoon.properties: 

producer. type .file = 

com .saba.web .engine.SabaProducerFromFile 



SabaSite 

SabaSite is an object containing a set of properties rel- 
evant to a particular saba application. These properties 
include, but are not limited to: 

File system location of application pages 
File system location of images 
Name of the site 

Name of the servlet driving this application 
Etc. 

Using the SabaSite object and the associated property file 
the configuration of a given Saba application can be changed 
with ease. 
The Algorithm 

The SabaProducerFromFile uses the request URL to iden- 
tify the file requested. The getDocument method of this class 
performs the following- steps: 

1. Determines the SabaSite based on the request. The 
SabaSite is identified as follows: 

a. Extract the servlet path information from the request 
object using the HttpServletRequest API 
(getservletpath( )). 

b. If the servlet path ends with a Web Content Server 
800 specific string suffix, then the associated Saba- 
Site name is determined by stripping of that suffix. 

c. If the servlet path does not end with the Web Content 
Server 800 specific string suffix, then the system 
default SabaSite name is retrieved using the SabaSite 
API. 

d The SabaSite is retrieved using the SabaSite API 
e. Finally the SabaSite is initialized using the request 
object 

2. Uses the SabaSite object to determine the location of all 
web documents by getting the document root property 
of the site. 

a. Uses the SabaSite API to retrieve the document root 
(getDocumentRoot( )). 

3. Determines the relative pathname of the requested 
document from the request object, 

a. Uses the HttpServletRequest getPath!nfo( ) API. 

4. Computes the absolute path of the document by com- 
bining the document root with the relative pathname. 

a. Appends the value of the document root and the 
relative pathname. 

b. Replaces all "V characters with "/" to make sure the 
absolute pathname has the correct syntax. 

5. Parses the file identified by the pathname and returns 
the resulting document object model (DOM). 

ControlFile Processing Algorithm 

When a client sends a request to a Web Content Server 
800 application, the above-described process is used to 
identify and parse the control file. The control file is an RDF 
document that ties the above-mentioned three components 
of the Model-View-Widget paradigm together. 
Control File Example 



1 <?xmi version-" 1.0" eacoding="UTF-8"?> 
2, <?cocoon-process type- i4 wdk"?> 

3 <!DOCTYPE rdf:RDF SYSTEM "../contra I l0.dtd"> 

4 <rdf:RDF xmlns:rdf="http://wvw.w3.orgtf ^ 
xmln3r^- M http://ww.Mba.com/XML/WDK"> 

5 <rdf: Description id="seaichPerson**> 
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6 <rdf:type rcsource="http7/www.sabaxom/XMLAVDKA2oatrorv> 

7 <wdk : ve rsio n > 1 .0 </wdi:vers ion > 

8 <wdk:model rdfcresource-"searchPcrson.xmr7> 

9 <wdk:view rdf:resource="searchPcrsonxsrv> 

10 <wdk: widgets rdf : resource^" .TxslAvidget/wdk^widgc ts Jtsl"/> 

11 <wdk:liokB> 

12 <wdk:link model^scarchPtrsonjan]" control="searchPersan.rdP '/> 

13 </wdk: links > 

14 </idf:E>cscriplion> 



15 </rdf:RDF* 



The control file contains a Cocoon processing instruction 
(line 2) that is parsed by the Cocoon engine. Hie cocoon 15 
engine uses the processing instruction to look-up the pro- 
cessor it needs to use to process the document. The Web 
Content Server 800 installation contains the following entry — 
in the cocoon.properties file: 

processor. type .wdk- 20 
com.saba.web.engine.ControlFile Processor 

This line tells the cocoon engine that the com. sab a. we - 
b.engine.ControlFileProcessor java class is responsible for 
processing all documents that contain a cocoon processing 
instruction of type="wdk". 25 

The control file processor performs the following steps: 

1. Identifies the model, view and widget files. 

2. Parses the model file and creates a DOM representation 
of the XML document. 

3. Inserts in the model file DOM: 30 
Cocoon processing instruction to invoke the Web Con- 
tent Server 800 transformer after the model page is 
executed. The Web Content Server 800 transformer 

is responsible for transforming the result of the 
model page using the widget and then the view XSL 35 
stylesheets. 

XSLT processing instructions to declare where the 
widget and view transformation stylesheets are 
located. This information was extracted from the 
control file in step 1. 40 

4. Updates hyperlinks in the model file based link map- 
ping information found in the control file. 

The control file processor returns the document object 
model containing all these updates, and the Web Content 
Server 800 engine then processes this DOM. 45 
Identifying Model, View and Widget File 

The control file contains the following three properties for 
encoding the three files: 

wdk:model: the rdf: resource attribute of this property is 
the path to the model file. (See line 8 in the example 50 
above.) 

wdk:view: the rdf:resource attribute of this property is the 
path to the view file. (See line 9 in the example above.) 

wdk:widget: the rdfcresource attribute of this property is 
the path to the widget file. (See line 10 in the example ss 
above.) 

Creating the DOM for the Model Document 

Given the path information in the rdf :resource attribute of 
the wdk:model property, the actual path is computed based 
on saba site information. The process of computing the path 60 
is almost identical to the process described under the File 
Loading Algorithm section. The only difference is that if the 
value of rdfiresource does not begin with the path delimiter 
character ("/") then the processor interprets the path as a 
relative path from the control file. Once the path is 65 
computed, the model file is parsed and a DOM representa- 
tion is generated. 



Updating the Model DOM 

Before the model page (its DOM representation) can be 
further processed by the wdk engine, a cocoon processing 
instruction <?cocoon-process type="xsp ,, ?> is inserted. This 
processing instruction instructs tne engine to first process the j 
model page using the xsp processor (see section below on 
Custom XSP Processor). The control file processor inserts 
another processing instruction: <?cocoon-process type= 
"wdk„xsl w ?>. This processing instruction directs the 
Cocoon engine to use the Web Content Server 800 specific 
XSLT transformer for the transforming steps (see section 
below on custom XSLT processor). Furthermore, two 
<?xml: stylesheet . . . ?>processing instructions are also 
inserted in the document object model following the above 
processing instruction. The "href* data component of these 
instructions identifies the widget and view stylesheets in that 
order. The Web Content Server 800 specific XSLT trans- 
former will process these two processing instructions to 
perform the XSL transformations. 

The following Java code shows how the processing 
instructions are inserted into the DOM: 

private void insertNextPI (Document doc, Processingln- 
struction pi) throws 



ProcessorException 
{ 

fry { 

NodeList nodelist = docgctChfldNodesO; 
Node theNode-null; 
Node lastPI=null; 
// End last PI 

for (iat i-nodeLisLgetLengthQ-l ; 1 >- 0 ; i — ) { 
thcNodc " nodcLisLitemQ; 
if (theNodcgetNodeiypcO — 
Node.PROCESSING_INSTRUCnON_NODE){ 
lastPI-theNode; 
break; 
} 

} 

if (lastPI— null) { 

// cound not find a PI so just get the first node 

theNode-nodeListitem (0); 
} else { 

//going to do an insertBefore, so we want to move to the next 
//node so that this new PI gets inserted AFTER the last PI 
tbcNode=IastPLgctNcxtSiblingO; 
if (theNode=null) { 
//should always have at least a root node after a PI 
throw new ProccssorExccption(" Error processing control 
file: need a root node after a processing instruction'*); 
} 

} // if lastPI—aull 

doc.tnsertBefore((Node) pi, theNode); 
} catch (DOMException e) { 
throw new ProccssorException("Uncxpected error processing 
control file: " + e.toStringO); 

} 

} /• insertNextPI •/ 
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Updating Link Information 

Model pages typically contain links that allow the model 
page to invoke another page. In order to make model pages 
reusable with different view pages, page references in a 
model page always refer to other model pages. This way 
different control riles can reuse the same model page but use 
two different view pages. However, links pointing to model 
pages have to be transformed to control page hyperlinks 
before the final document is produced, since the request 
URL has to contain information about the control file and 
not the model file. In order to perform this transformation, 
the control file contains information about how to map a 
model page reference to a control page reference. The 
control file contains a single wdk: links element, which 
contains a number of wdk: link elements. Each wdk: link 
element has two attributes: model and control. The model 
attribute is the hyperlink name of a model file, while the 
value of 'the' control attribute is the hyperlink name of the* 
control file. 
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The control file processor locates the wdk: link and 
wdk: links elements in the control file DOM using the 
standard DOM API. Once all wdk:links elements are 
located, the control file processor inserts a wdk:linkMap 

5 element in the wdk:head element of the model DOM, and 
then inserts one wdlclinkMapEntry for each wdk.link found 
in the control file using the DOM API. The wdk:linkMap- 
Entry element has the same attributes as the corresponding 
wdk: link in the control file. This way the mapping informa- 

1(J tion is made available in the model page, and can be used by 
either the model page itself or the subsequent widget and 
view transformations. For example, the wdk:link widget 
makes use of this information to transform model page 
references to control page URLs. 

is EXAMPLE 

The Model DOM Before and After the ControlFileProcessor 
The following code sample shows the XML serialized 
" version "of a model' file " before "the" ControlFileProcessor' 

updated the DOM. 



<?xml vemion- M 1.0"?> 

ocspqpagc Ianguage="java" janliB^p="http^/www^pachc.org/1999/XSP/Corc" 
xmlns :wc!ktag^"http:/Avww.saba.conVXMlVWDK/taglib , '> 
<xsp:structure> 

<xsp:includc>com.saba.cxccption.*</xsp dncludo 



<frsp:structwe> 

<wdk:page xmlns rwdi-"http ://www.saba.com/XML/WDK"> 
<wdk:hcad> 

<wdklags:in> 

<wdktags:param name- M sessionKey7> 

<wdktags:param namc= - actionKcy" requircd="felsc" typc= "String" default** 4 "'^ 

<wdloags:param name-"personSearch*7> 
</wdktags:in> 
<wdktags:out> 

<wdk:param name="sessionKey" type=" String" iequired=»"true7> 
<wdfcparam name="actionKey^ type^String" requLred="false"/> 
<wdfcparam namc»"personScarch" typc-"String" rcquircd-"truc"/> 

</wdktags:out> 

<xsp:logic> 

Session sabaSession - SessionManager.getSession(sessioiiKey); 
String desiredLang = (String)sabaScssion.gctBl(*("selecte(3Language**); 
</xsp:logio 

<wdktags:il8n.load resource-"party_labels"> 

<Ianguagc><xsp :cxpr>dcsiredLaiig</x5p :expr></language> 
</wdktags:il8n.load> 

<wdk.-titIe><wdktags:il8Q. Label name-"kll8n6000SearchForPeopIcLabcl7> 

<wdk.*title> 

<wdlclabels> 

-ewdkilabel naine-"busUnitLabel"><wdktags:i38n.label 
name-^18n6008Businc5sUniil^be]7></wdk:label> 

<wdtlabel name=**locLaber*><wdktags:il8ii.label 
namo-"kll8n6000LocatioiiLabel7><Avdk:[abel> 

•cwdblabel namc="firstNaincLabcr><wdktags:il8ii.labeI 
name-^18n6000RegularFirstNameLabel7></wdk:label> 

<wdi:label nflme-"lastNameLabel%<wdktags:il8o.label 
namc-^118n 6000 Regular La5tNamcLabcr7></wdk:Iabcl> 

•cwdfcrlabel Qame= M locadoaLaber><wdktags:Ll8iLlabel 
name-^18n60(X)Regailarlx>cationLabel , 7>-<^wdt:label> 

<fwdk:labcls> 
<AvdJchead> 

<wdlc:form method- u GET"> 
<wdi:hiddcn_ficld> 

<namc>sessionKey</name> 

<valuc><xsp:cxpr>scssionKcy</xspxxpr><valuc> 
</wdk: hiddeo_field> 
<wdk:hidden_field> 

<name>actio nKey<^name> 

<valuc>scarch </value> 
</wdk: hidden„fi£ld> 
<wdk: model> 

<xsp:logjc> 
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if (actio riKey. equals ("search")) 

{ 

<people> 

<wdktags:execute 

managerte"o}in.saba.dienLf>any.beansTersoaCoinmandMaiiager oommand-^earchForPcople" 
argument-"personSearch'7> 

</pcoplc> 
}/* if actionKey.equal("search")'/ 
</xsp:logic> 
</wdkrmodcl> 
</wdk:form> 
<wdk:widgets> 

<wdk:input namc="lastNamcFicl(f*> 

<label><wdktags:il8n. label name=«' 4 kllfin6000LastNamcLabcl7></label> 
<id >personSearch</id> 

<^aluc><^p:cxpr>pcisciiScarch<^sp:cxpr></valuc> 
<fwdlcinput> 
<wdk:ltnk name*»"go"> 

** <td>GO<tfd>- —" — ■ ' 

<hrcf>searchPcrson.xml</href> 
<type>button</type> 

<labc 1 xwdktags : il 8a. bbc 1 name="kll8n6XXXXXG07></label> 
<prompt><wdktags:il8n. label nam e=*Tcll 8n 6XXXXXGO"/x/p rompt> 
</wdk;lijik> 
</wdkrwidgcts> 
<ywdfcpage> 
</xsp:page> 



The following code sample shows the same model file 
after the ControlFileProoessor updated the model file. The 
changes are shown in bold face: 



<?xml version-" 1.0"?> 

<?cocoon-process type="xsp"?> 

<?cocoon-proccss type="wdk_jtsF'?> 

<?rml stylesheet href-"-/xsl/widget/wd k_widget8.xsT?> 

<?xml stylesheet href="sean:hPerson.xsP? > 

<xsp:page language="java" xmins:xsp= M hUp^/www.apache.org/1999/SXP/Cdre" 
xinins:wd]ctage-"hitp://ww.saba.TO 
<xspstructuie> 

<isp:include>com^aba.exception. p </xsp:iiiclude> 



</xsp.structure> 

<wdk page xmlns:wdk="httpyAvww j5aba.c0m/XM L/WDJC^ 
<wdk:head> 

<wdktags:in> 

<wdktags:param oame="sessionKey*7> 

cwdktagsrparam oame^actionKey** required=**false" type=**String" default=*"7> 

<wdktags:param name— a personSearch"/> 
</wdktags:in> 
<wdktags :out> 

<wdk:param namc-"seaaionKey" type-" String" required-"true"/> 
<wdk:param najne=^actionKey> type="String" required-"false , 7> 
<wdk:param name-^personScarch" type— "String" required- 4 true"/> 

</wdktags:out> 

<csp:logic> 

Session s aba Session = SessionManager.getSession(sessiooKcy); 
String desiredLang - (String)BabaSession.getBlobC"sele<:tedLanguage''); 
<frsp:logic> 

<wdktags:il8n.load resource-"party_labels"> 

<Janguage> <xspxxpr>dcsircdLang</sjq): eatpr></language> 
■e^wdktags : il 8n.load> 

<wdk:title><wdJctags:il8n.labcl name="kI18n6000SearchForPeoplcLaber7> 
</wdk: title > 
ovdk: labels > 

<wdk:label name= M busUnitLaber'><wdttags:il8n.label 
name-"KI18m6O08BusineasUnitLabcr7><^wdk:labeI> 

<wdk:label name="locLaber'xwdklags:il8rj.label 
name-"kll8n6000Loc«tionUter/>Vwdk:labeI> 

<wdk:label narne«"ftrstNameLaber><wd]0ags:il8Q.label 
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name="kl 1 8n6000 RcgularFirstNameLaberVx/wdk: labcl> 

<wdk: label name»**lastNameLabei"><wdktags:il8iLlabel 
name-"kl 1 8n6000RegularLastNameLabcr V> V*dk:label> 

<wdk:label name^locationLabcr'xwdktagsrilSn. label 
narne= M kll8n6000RegularLocatioriLaber7></wdk:label> 
</wdk:Iabels> 
<wdk:linkMap> 

<wdk:lmkMapEntry model="searchPersonjonr control" searchPerson.r«JF/> 
</wdk:linkMap> 
</wdk:hcad> 

<wdk:fonn method="GET'> 
<wdk:hidden__field> 

<namc>scssionKcy</oamc> 

<value><zsp :expr>sessionKey </xsp :expr></value> 

</wdk:hidden ficld> 

<wdk:hiddcn__ficld> 

<name>actionKey </name> 

<value>search</value> 

**" </wdk:hiddcn__ficld>* " * *" "" " " ' ~* - — . ■ - 

<wdk:model> 
<xspJogic> 

if (actionKcy.cquals("scarch")) 
{ 

<people> 

<wdktags:exccute 

manager*"co iiLsaba-dicnLparty.bcans.PersoQCoinmandManager" oommand=» M searchForPeople'* 
argument=**personSearch"/> 

<tfpeople> 
}/* if actionKcy.cquals("search")7 
<tfxsp:logic> 
</wdk:model> 
</wdk:fbrm> 
<wdkwidgets> 

<wdk:input name-"lastNameFIeld"> 

<iabcl><wdktag5:il8n.labcl namc-"kll8n6000LastNamcLaber , /></labcl> 
<id>personSearch</id> 

<vaIue>-<xsp:expr>pcisoaSearch^/xsp:expr>^/value> 
</wdk:input> 
<wdk:link name="go"> 
<id>GO</id> 

<:hrcf>scarchPcrsoa.xml</hicf> 
<type>butto a</typc> 

<bbel><wdktags:il8n.label namc- 4 'kU8n6XXXXXGO"/></label> 
<prompt><wdktagsil8rL label namc= u kll8n6XXXXXG07>^/prompt> 
</wdk:link> 
</wdk:widgets> 
</wdipagc> 
</xsp:page> 



Custom XSP Processor 

Instead of using the XSP processor of Cocoon, Web 
Content Server 800 uses a custom XSP processor. To make 
this happen, the following line is added to the cocoon.prop- 
erties file: 

processor, type. xsp 

=<:om.saba.web.engine.SabaXSPProcessor 

This processor adds the following capabilities: 

Debugging: The Web Content Server 800 XSP processor 
can produce intermediate files representing the docu- 
ments as the model page is transformed from its 
original form to the java code that is executed and the 
actual data that is produced by the java code. These, 
intermediate files can be inspected to locate the source 
of a problem more easily. 

Cache control: For debugging purposes it is important to 
know that the code that executes is the code that the 
developer has just edited. However, the cocoon engine 
contains a number of caching mechanisms that make 
this assumption incorrect sometimes (ie. The code 
that's executed is code that is in the cache instead of 
code that the developer has just changed). The Web 
Content Server 800 XSP processor allows control over 
caching. 



45 



Producing Intermediate Files for Debugging Purposes 



The SabaXSPProcessor can produce intermediate files as 
the model file goes through the different transformation 
steps. The helper classes XSPDebugger and DebuggerCon- 
fig are used to control which if any intermediate files should 
50 be produced. The following properties are introduced in 
cocoon.properties for controlling debugging behavior: 

wdkdebugoutput 

wdkdisable cache 
55 wdkdebug 

The wdkdebug property can have the following values: 

off: No debugging information is produced 

full: Every intermediate file is produced 
60 wdktags: Only the result of the wdk tag library transfor- 
mation is output 

wdk: Only the result of the widget library transformation 
is output 

65 xsp: Only the result of the xsp transformation is output, 
model: Outputs the result of executing the java code 
produced from the model page. 
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The wdkdebugoutput property can have the following 
values: 

sourcedir: The output files are placed in the same direc- 
tory where the source documents are read from. 

browser: The output files are sent to the browser 

repository: The output files are placed in the cocoon 
repository directory. 

The wdkdisablecache can either be "true" or "false". If 
true the cocoon cache is not used. 

The init method of the SabaXSPProcessor creates an 
instance of the DebuggerConfig class, and the process 
method creates an instance of XSPDebugger. The XSPDe- 
bugger is a subclass of Debugger and it uses the Debugger- 
Config object to read the debugger configuration from the 
cocoon.properties file. 
The Debugger and XSPDebugger^Classes 

The Debugger has the following API: 

public void readParameters(Dictionary parameters, 
DebuggerConfig config); 

This method initializes the Debugger with the current 
debugging property values, 
protected boolean debugThis(String rule); 

The method returns true if the wdkdebug property is 
either "full** or matches the rule parameter, 
protected boolean browserOnly( ); 

The method returns true if the wdkoutput property is set 
to "browser". 

public boolean cacheDisabled( ); 

Returns true if the wdkdisablecache is true. 
The XSPDebugger introduces the following methods: 
public boolean debugLogicsheet(String rule, Document 

document); 

Returns true if Debugger.debugThis(rule) is true AND if 
Debugger. browserOnly( ) is true. If only 
Debugger.debugThis(rule)is true, then first saves the inter- 
mediate result before returning false, 
public void debugFinalXSP(Document document) 

If the the wdkdebug property is full or set to model then 
the result of executing the code produced from the model file 
is output. 

Custom XSLT Processor 

The default XSLT processor that comes with Cocoon 
performs a single XSLT transformation only. However, Web 
Content Server 800 requires two XSL transformations after 
the java code produces the data. The first transformation 
replaces the widgets with their HTML representation (the 
widget transformation) while the second transformation 
renders the data (the view transformation). To make the 
engine aware of the Web Content Server 800 XSLT 
processor, the following line is added to the cocoon.prop- 
erties file: 

processor.type.wdk_xsl-com.saba.web.engine.WDK^ 
XSLTProcessor 

The Web Content Server 800 XSLT processor takes as 
input the document object model produced by executing the 
XSP page. The processor extracts the xmhstylesheet pro- 
cessing instructions from the DOM, and executes XSL 
transformations using the stylesheet documents referred to 
by the "href data element in the processing instructions. 
(The xml: stylesheet processing instructions were inserted in 
the source document by the control file processor — see the 
ControlFileProcessor algorithm section for details). After 
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each transformation step, if the debugger flags are set, the 
DOM is serialized and saved to a text file. 

The following code snippet shows how the widget and 
view transformations are performed: 



try{ 

/* get all stylesheets referred to by this document •/ 
Vector resources = gctRcsourccs (document, request, context); 
10 F apply each stylesheet in turn */ 
Enumeration e - resources.elementsQ; 
while (chasMoreElementsO) { 

Object resource - tnatE2ement(); 
this.logger.log(this, "Processing stylesheet " + 
resource .toStringO, Logger.DEBUG); 
15 Document stylesheet » getStylesheet(resource, request, 

lxsltDebugger.cacheDisabled0); 
Document result = Ihis-parsctcrcateEmptyDocumentO; 
document =» transformer.tramfo mi (document, null, stylesheet, 

resource.toStringO, result, params); 
if (xsltDebugger.dcbugStyleshcet(document > resource)) { 
20 //requested debug output to browser, so done now 

return document; 

} 

} 

return document; 
} catch (PINotFoundExccption c) { 
-e return document; 



Custom XSP Page Class 

Each XSP page (model page) is transformed to a java 
30 object (source code generated, compiled and the class is 
loaded). In Web Content Server 800 the generated java 
objects are instances of the SabaXSPPage class, which is a 
subclass of the XSPPage class. (The XSPPage class is the 
default class provided by Cocoon.) In order to change the 
35 class from XSPPage to SabaXSPPage, the following 
changes had to be made: 

1 . Create a new xsp-java.xsl taglibrary stylesheet based on 
the default stylesheet that comes with Cocoon: 

a. Change the class declaration line to extend SabaX- 
40 SPPage instead of XSPPage as follows: 

public class <xsl:value of select-" @name"/>extends 
SabaXSPPage { 

b. Invoke the initialization method specific to SabaX- 
SPPage in the populateDocument method: 

45 initializeOnRequest(request, response); 

This method initializes protected site and logger vari- 
ables. (See below) 

2. Change the cocoon.properties file by adding the fol- 
lowing line: 

50 processor.xsp java.logicsheet=/corn/saba/web/engirje/ 
xsp-java.xsl 

The SabaXSPPage class provides model pages access to 
frequently needed information including: 
5S Site: information about the SabaSite object representing 
the current saba site. 
Path information: extracted from the Saba site object for 
convenience 

Access to a logger for debugging and status messages 
60 SabaXSPPage declares protected member variables for 
each: 

protected SabaSite wdkSite; 
protected Logger wdkLogger; 
protected String wdkBaseURL; 
65 protected String wdkRoot; 

These variables are therefore accessible by model pages 
and by the tags defined in the wdktags tag library. 
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Structure of Model Pages 

Model pages are Extensible Server Page (XSP) pages. 
XSP pages can contain a mix of static content and content 
generating programming logic by using xsp directives (tags) 
defined in the xsp tag library. Furthermore, an XSP page can 
make use of an indefinite number of application specific tag 
libraries. A Web Content Server 800 model page uses the 
wdktags tag library to simplify certain common program- 
ming tasks. 

Web Content Server 800 model pages have a very well 
defined structure. The document element of the page is 
<xsp:page>. The document element can contain <xsp:struc- 
ture> and other xsp directives, but it can contain a single 
non-xsp element only. For a Web Content Server 800 page 15 
that element is wdfcpage. The wdk:page element consists of 
the following subsections: 

wdk:head — contains internationalized labels, the page 
title, image references, link mapping information 
(generated automatically from the control file by the 
control file processor). 
wdk:form — The wdkrform element is one of the elements 
in the widget library. Since most wdk pages are HTML 
forms, the wdk:form element is used to generate the 25 
HTML form and javascript functions required by a Web 
Content Server 800 application. For example, a javas- 
cript function is generated that can be called by link 
widgets to submit the form, 
wdkrwidgets — widgets (input fields, buttons, hyperlinks, 30 

etc.) are all listed in the wdkrwidgets section. 
The wdkrform element can contain the declaration of 
hidden fields needed by the application, and it contains a 
singe wdk: model element. The wdk model element contains 
all "data" generated by the page. 

Often all the wdk: model section contains is invocations of 
Commands that produce the appropriate XML content. 
Separating Content from Interaction 

An important property of model pages is the ability to 
generate/declare dynamic content (through commands) and 
interaction elements (widgets) independently of each other. 
This separation of content and widget generation allows for 
greater reusability. However, at the end of all the processing, 
the widgets and the content have to be combined. For 45 
example, an input text field (a widget) and the "name" 
property of a business object have to be connected/combined 
some way to make sure that that particular text field can 
display that particular property. This connectivity between 
model elements and widgets is achieved by Web Content 
Server 800 tag library tags. 

The wdktags: attachTo tag can be used to "attach** (copy) 
a particular widget to a model element. 

For example, a software engineer may author the follow- 
ing simple model document: 
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<wdk model> 
<domain> 

<name>Domain 1 </name> 
<dd>idl</id> 
</domain> 
<domain> 

<name> Domain 2</name> 
<id>id2<^id> 
</domain> 
</wdi:model> 
</Wdfcfonn> 
<wdk:widgets> 

<wdk: input name» **cdilNamc"> 

<wdktags:attach.Tb path- "domain'7> 
<vahic><wdklags :nodeRcf path= "name*7></value> 
</wdk:iiiput> 
</wdfcwidgets> 
</wdk:page> 
</xsp:page> 



The document resulting from processing the Web Content 
Server 800 tag library and the XSP engine execution will be: 



<wdk:page> 
<wdkhead> 
</wdi:head> 
<wdkform> 
<wdk:modcl> 
<domain> 

<namc>Domain l</namc> 
<id>idl</id> 

<wdk: input name= ~editName"> 
cvatooDomain l</valuc> 

</wdk:input> 
</domain> 
<domaio> 

cname> Domain 2</namc> 

<id>id2</idj> 

<wdk: input name- "editName**> 
<vahie>Domain 2-^valuo 
</wdk:input> 
<ydomain> 
<Avdk:modcl> 
</wdk:forcn> 
<wdlcwidgets/> 
</wdk:page> 



<xsp:page language- java 

xmlp3^-"htt P ://www,aDachc.org/1999/XSP/Cor e " 
xmlra:wdktaiB° H httD://www.saba.coin^MUWDK/ta g liV- 

> 

<wdk:pagc> 
<wdk hcad> 
</wdt:head> 

<wdk:form method- "POST"> 
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Note that the attach To directive effectively created a copy 
of the input widget inside each domain element. 
Furthermore, the nodeRef directive has been replaced with 
the text value of the element it refers to in its path attribute. 

The following describes the implementation of the 
attachTo tag. 
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1 <xsl:template match="*[wdktags:attacb'lbj , > 

2 <xsl:variable name«**rootNode"> 

<xsl:choose> 
<xsl:when test="wdktags:auachTb/@root**> 

<xsl:value-of select»**wdklag$ :attachTb/@roct7><tfcsl :whcn> 
<xsl:otherwise> 

WDKI>DmUin3.gctModclNodc(xsp<^cntNodc.gctOwrrcrI>x^mciitO' 
getDocumentElemeatO) 
</xsl:otherwise> 
</xsl;cboosc> 
</xslrvariable> 

3 <xspJogio 
{ 

List wdkNodes = WDKDomUtils.getNodes((Element)<xsl.'value-of 
seIect-"$rootNode7> "<xsl :value-of selcct-"wdktags :attachTb/@path"/>'*) ; 

4 if (wdkNodes — null) { 

throw new RuntimeEbiception("Could not find node: <xsl rvalue -of 
select-*Vdktags:attachTo/@patli7>'0; 

Iterator wdklter = wdkNodesiteratorO; 
while (wdkItcr.hasNextO){ 

5 wdkwidgctNodc - (Nodc)wdtItcr.ncxtO; 
wdktagsNodeStackpush(xspCurrentNode); 
xspCurrentNode - wdkwidgetNode; 

6 if (xspCurrentNode — null){ 

throw new RuntimeException("Null node in node list"); 

7 <xsp:content> 

<xsl:copy> 

<Jtsl:app1y-templates selects" *|@*7> 
</xsl:copy> 
</xsp:content> 

8 xspCurrentNode = (Node)wdktagsNodeStack .popQ; 
} 

</xsp:logic> 
</xsl:teinpIate> 



Line 1 specifies the match condition: this template will 
match any element that contains a wdktagsrattachTo sub- 
element. Section 2 contains XSL logic for determining what 
root element should be used as the starting point for the 
value of the path attribute. If the developer specifies a root 
attribute, then the value of that attribute is used, otherwise 
the root element defaults to the wdk.model node of the 
model page. Section 3 invokes the getNodes( ) method on 
the WDKDomUtils class. That method returns the set of 
nodes that can be accessed from the root node through the 
path given in the path attribute of the wdktagsrattachTo 
directive. Section 4 checks for error conditions and sets up 
the iteration through the set of DOM elements returned in 



section 3. In section 5 the current xsp node (the value of the 
xspCurrentNode variable) is saved on a stack, and its value 
is replaced with the next node from the set of nodes returned 
in section 3. Since the XSP processor uses the xspCurrent- 
Node variable to mark the current "insertion point" — i.e. the 
location where the next DOM node will be inserted in the 
Document, this operation effectively copies the current 
subtree (the widget) to each node returned in section 3. 
(Sections 6 and 7 perform the actual copying.) Finally, 
section 8 restores the value of the xspCurrentNode and 
resumes the iteration. 

The following section describes the implementation of the 
nodeRef tag. 



1 <xsl: template match="wdktags:nodeRcf'> 

2 <xsl:va liable name-"root"> 

<xsl:choose> 

<xsl:when test«"@source"><xsl^lue-of seIect="@source"/></xsl:when> 
ocsl :otherwise>wdkwidgetNodc</xsl :otherwisc> 
</xslxhoose> 
</xslrvariable> 

3 <xsp:logic>{ 

Element wdkChildNode = WDKBomUtils.getChildNode((Elcment)<xsl:vaIuc-of 
select- M $ioor/>,"<xsl:varue-of select-@path7>"); 

<xsp:content><xsp:expr>WDKI>>mUttfs.getTetf^ 
} 

<frsp:logio 
</xsl:lemplate> 
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Line 1 specifies the match condition: this rule matches element, the <head> element containing the <title> element, 

every nodeRef tag. Section 2 determines the root node: if the These common templates are all grouped in a default 

source attribute is given then the value of that attribute is stylesheet that can be imported using the <xsl:import> 

used, otherwise the value of wdkwidgetNode Java variable directive by every view page. As a result, for simple pages, 

is used. The wdkwidgetNode variable is initialized in the me view P a g e needs to contain a singe cusomized xsl:tem- 

wdktags:attachTo template described above. This way, if P late mal matches on the "wdkrmodel" node. This 

nodeRef is used in the context of an attachTo tag, the root template is responsible for rendering the data as well as the 

node is the same node the widget is copied to. The actual widgets. 

node whose value is needed is located by following the path 10 EXAMPLE 

from the root node. Finally, the text value of the node is Default 'View Transformation Templates 



1 <?xml vcision="l.Cr*?> 

<xsJ stylesheet version«"1.0" xmlns:xsl=' , htrp;//www. w3.org/1999/XSUTransfonn" 
xmlns rwdi-"http://www.£aba.coin/XML/WDK' , > 
<xsl:output mcthod="xmr indenl-'*ycs7> 
<xsl:s trip- space elemen£s="*"/> 

2 <xsl template match-V> 

<xsl:variablc name ="titlcLaber><xsl :valuc-of sclcct^"//wdthcad/wdk:titlc"/></xsl rvariablo 
<html> 
<head> 

<title><xsl: value- of sclect-"$titleLaber7></titlc> 
</head> 
<body> 

<X8l:appIy-templatcs/> 
<rtx)dy> 
</html> 
</xsl; temp late > 

3 <xsl:template match="* | @*|textOlcommentO" priority="-l"> 

<xsl:copy> 

<xal:apply-template3 select-"* | @*|text0|comment0'7> 
<Acsl:copy> 
</xsl:template> 

A <!— eliminate the wdk:head element and all children of wdkwidgete--> 
<xsl: temp late match=wdk;hcad | wdk :wid gets > 
</xsl: temp late > 

5 <! --replace widget with span (so we can do CSS on it) and process their children -> 
<xsl:templatc match="wdk:widget"> 

<span class="{@name}"> 

<xsl :apply-templates/> 
</span> 
<br/> 
</xsl: temp late > 

6 <xsl:tcmplate match=» u wdk:pagc"> 

<xsl:app!y-templates/> 
</xsl: template > 
</xsl: stylesheet 



computed by calling the WDKDomUtils.getTextvalue( ) 
method. 

Structure of View Pages 

Mew pages are XSLT stylesheets. The role of the view 
stylesheet is to convert the XML document produced by 
executing the model file (and the subsequent widget 
transformation) to a format understood by the user agent. 
For example, for desktop browsers this typically means 
conversion to an HTML representation. Since model pages 
have a well-defined structure, view pages are also highly 
regular. For example, there are a number of model page 
elements that should not be rendered (such as wdk:head 
element and its content should not be copied to the output). 
Other model pages nodes have a standard representation in 
HTML (or in the desired output format). For example, the 
rule for rendering wdk:pagp is to generate the <btml> 



50 Section 1 defines the namespaces used in the stylesheet. 
Section 2 defines the root level template. This template 
produces the html tags, and generates the html head element 
complete with the title element. Section 3 defines the default 

55 template: every element, attribute, text and comment is 
copied to the resulting document, unless a more specific 
template provides different instructions. Section 4 specifies 
a template for eliminating the wdk:head and wdk: widgets 

60 elements and their contents (since the contents of these tags 
should not be rendered using the default template defined in 
section 3). Section 5 introduces a template for transforming 
every widget by wrapping them into a span element replac- 

65 ing the wdk widget "wrapper". This makes it possible to use 
CSS styling on a per named-widget basis. Finally, section 6 
defines the template for processing the wdk:page element. 
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1 <?xml vereion="1.0"7> 

<xsl:3tyteaheet version-"! .0" xmlns 3Esl-"http;//www. w3.org/1999/XSL/Tran3form" 
xminsrwdi=" http7/www.saba.com/XML/WDK"> 

2 <xsl: import hie f=*7 . .xs 1/vie w/wdk_defa ul tview.xsl' '/> 

3 <xsl:template ma tch-" wdk: mode I" > 

4 <h2 align="center"><xsl:value-of sclea""Avdx:pageAvdk:headAv(lk:tit]e*V></h2> 

5 <p> 

<KsIrvalue-of select-7wdkpage/wdk:head/wd^labeIsA*^ 

6 <xsl:for-cach select="parcnts^parent"> 

ccslrvalue-of selecto"name"/> 
<xsl:text>> </xsl:text> 
</xsl:for-cach> 

<xsl:value-of select='*parcnts/lea&aame"/> 
</p> 

7 <xs I :apply- templates scl ect«"/Avdi; .-widgct"/> 

8 </xsl:template> 
<tfxsl:stylesheet> 



20 



Section 2 imports the stylesheet containing the default 
templates. Line 3 defines the rule for processing the wdk- 
:model node, line 4 displays the title of the page by 
accessing the wdk: title tag inside the wdk:head tag. Section 
6 iterates through each "parent" element inside the wdk- 25 
rmodel element and displays its name. In section 7 any 
widget produced by the model page is displayed. 
The wdk Taglibrary 

The wdk taglibrary contains a number of tags to simplify 
the development wdk model pages. The tag library includes 30 
tags for: 

handling resource bundles for page internationalization, 
invoking commands to generate XML representation of 
the data retrieved from the database, 



managing the connectivity between widgets and the pro- 
duced data model, 

managing the input and output parameters to the model 
page, 

etc. 

To make the tag library accessible by the processing 
engine, the following line is inserted in cocoon.properties: 

processor.xsp.logicsheet.wdktagsjava-s:/sys/java/web/ 
com/saba/web/xslAaglib/wdl^_taglib .xsl 

The value of the above property identifies the location of 
the taglibrary stylesheet. The taglibrary stylesheet contains a 
number of xsl: import directives to import templates respon- 
sible for implementing subsets of tags and it also contains a 
number of default templates, as the code example below 
shows: 



<?xml version="l.(r cncoding="UTF-8* , ?> 

<xsl: stylesheet version="1.0" xmlnsDKl=~http:/Avww. w3.org/1999/XSL/Transform'' 
xmlns :xsp-"http://www.apachc.org/1999/XSP/Core" 
xmlns rwdktags="http ://www.saba. com/XML/WDK/taglib" 
xmlns :wdk="http://www.saba.corri/X3vlL/WDK , '> 
<xsl: preserve- space elements-** *"/> 
<xsl: include hrcf«'*wdk__pararrLxsr7> 
<xsl: include hrefV*wdk__L18n.xBry> 
<xsl: include href-"wdk_command.xsr/> 
oral: include hrcf- u wdk_control.JCsl , V> 
<xsl: include href»"wdk__site.xsP* /> 
<xsl:template match-"xsp:page"> 
<xsl:copy> 

<!-need to explicitly call some logic in the wdt_command stylesheet -> 
<xsl:call- template namc= M command_header'7> 
<!-nced to explicitly call some logic in the control stylesheet --> 
<xsl:cail-template name="control_header*7> 
<xsl :apply-templates/> 
</xsl:copy> 
</xsl:template> 

<xsl: template match="@*|*|textQ|processing-instructionO|comment()" priority-"- 1"> 
<xsl:copy> 

<xsl:apply-templates select^"@*|*|textO|proce«ing-instractionO|coriimentO' , /> 
</xsl:copy> 
</xsl:template> 

<xsl: template match="wdk:head"> 
<xsl:copy> 
<wdk:Bite> 

<hrcf >/<xsp :expr>wdkRoot<&sp: expr>/</hrcf > 

<imageRoot><xsp:expowdtSite.geUirageRootO</xsp:expr><yimageRoo^ 
<sabaservlet><xsp:expi>WDKSabaU^ 
> 

<sitename><xsp :expr>wdkSite.getName() </xsp:expn></sitena me> 
</wdk:site> 
<xs 1 :apply-te mpl ates/> 
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-continued 



</xsl:copy> 
</xsl:template> 
</xsl:stylesheet> 



An Example: wdktags:param 

The wdktags:param is one of the tags defined in the wdk 
tag library. The purpose of this tag is to simplify the 
extraction of parameters from the HttpServletRequest 
object. Traditionally, JSP, XSP or servlet programmers have 
to write a number of lines of code for the parameters they 
want to process. The code for each parameter is typically 
similar to the following: 



Each parameter can be defined with a single line of XML 
code and as a result of this line the developer can use a Java 
variable named "param" in their code wherever the value of 
the "param" HttpRequest parameter is needed. The wdktag- 
srparam tag is implemented in wdk_param.xsl, and is 
imported by the main taglibrary stylesheet. The following 
code shows the implementation of wdktags: param: 



1 <?xml veraion- M 1.0" encoding-"UTF-8"?> 

<xsl stylesheet version="1.0" xmlos:xsl="h tip :/Avww. w3.org/1999/XSI7Transform" 

xrrilns:xsp="http7/vvn^.apachcxTg/1999/XSP/Core'' 

xmlnsrwdktags-"http ://www.sftbaxom/XML/WDKD/taglib"> 

2 <xsl template mateh»"wdktags:in/wdktags:param"> 

3 <xsp:logjc> 

<ral variable name-"paramName"><x»l^fthie-of select-"@name'7><^X3lrvariable> 
<xskvariabic namc="paramTypc"> 
<xsl:choose> 

<xsl:when tcst-"not((^ypc)">String</x8l^vhcri> 
<xsl:whcn test='*type» < ID"'>Strirjg </xsl:whcn> 
<xst:otherwise><xslrviilue-cf select="@typc"/></xsl:oLherwise> 
<tol:choose> 
</xsl:variable> 

<xsl:va liable name»"paramRequiretf'> 
<xsl:choose> 

<xsl.-whcn test=* 1 Dat(@rcquircd)">felse</x5lwhen> 
<xsl:otheiwise><xsl rvalue -of select=@"requircd'7></!JEsl:otherwise> 
</xsl:choose> 
</xslrvariab]e> 

<xslrvariable name= M paramDefaul t"> 
<xsl:choose> 

<xsl:whcn test="@defauU!«- w, ><3islrvalue-of sclcct«"@dcfault , 7></xslrwhcn> 
<xsl:when test="(^efault»"">""</xsl:when> 
<xslrwhen tcst="not(@de£ault) and @type=-' Strirtg'"> rT,, </xsl :when> 
<xsl :otherwisc>null/xsl :othcrwise> 
<tal:choose> 
</xsl:variable> 

4 <xsl:va!uc-of sclcct-"$paramTypc'7><xsl:tcxt> <Jxs\ :text><xsl:value-of 
sclect= li $paramName"/>=request.getParameter("<xsl:value-of select="$paramName M /> w ); 

if (<xsl:value-of select="$paramName7> = null) 

<xslrvalue-of aeIect- u $paramName"/> - <xsl:value-of select-"$paramDefault'7>; 

</xsp:logio 
</xsl:template> 
</3tsl:styleaheet> 



String param=request.getParameter("param"); 
if (param==null) {param="some default"; } 

The wdktags:param tag intends to simplify this by allow- 
ing developers to declare what parameters they want to use 
in the model page, and the mundane task of extracting the 
parameter is performed by the tag itself. Thus, Web Content 
Server 800 developer can write the following in the <wdk- 
:head> section of the model page: 



<wdktagsnn> 
<wdktags:param name- "param" type- "String"> 
default- "some default" required- "tme7> 
<ywdttag5:in> 55 



Section 1 declares all namespaces used in the stylesheet. 
In line 2 the match condition is given for the template. This 
template matches on every wdktags:param tag inside a 
wdktags: in tag. This nested condition is necessary, because 
a different template may transform wdktagsrparam tags 
inside the wdktags:out tag. Section 3 computes the values to 
use for parameter type and parameter default value. These 
values are either determined from the values of "type" and 
"default** attributes of the wdktags:param tag, or default 
values are selected (the java String class for type, and the 
java null constant for default). Section 4 produces the java 
code declaring the java variable by the name given in the 
"name" attribute of the param tag, and the value is initialized 
either from the HttpServletRequest object or by using the 
default value computed in line 2. 

Tags Defined in the Web Content Server 800 Tag Library 
wdktags:param Provides a convenient method for declar- 
ing and using parameters passed in through the HttpServ- 
letRequest. 
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wdklags:siteRef: Generates an absolute URL from a rela- 
tive URL based on the current site information. 

wdktagsxxecute: XML fragments produced by Java 
objects (Commands) can be embedded in the resulting 
model document using the execute tag. 

wdktags:il8n.load: Declares the il8n resource bundle to 
use for the labels in the page. 

wdktags:il8n.path: Generates internationalized image 
path information using site parameters and information from 
the resource bundle specified by wdktags:il8n.load. 

wdktags:il8n .label: Retrieves internationalized labels 
from the resource bundle specified by wdktags:il8n.load. 

wdktags:attachTo and wdktags:nodeRef: As described 
above these tags can be used to assign widgets to model 
elements and to add data dependent information to widgets. 

wdktags: repeat Provides the capability to replicate wid- 
get components based on elements in the generated model. 
Used mainly by list widgets to generate the set of options 
dynamically. 
The Widget Library 

The Web Content Server 800 widget library contains rules 
(XSLT templates) for transforming a number of widgets to 
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get information from the user, he or she needs to use the 
wdk: input widget. Here is an example of using the input 
widget: 



<wdk:input name- "inputZip"> 
<id> inputZip </i d> 
<size>5</size> 

<m axle n gth >5 </max lc ng th> 
<value>60202 </valuc> 
<label>Enter the zip code</label> 
<rcquired>false </requircd> 
<password>false</password> 
</wdk:input> 



20 The widget transformation transforms this document frag- 
ment to the following: 



<wdkrwidget name»"inputZip"> 

<span align- "left" class» "Input_Label">Enter the zip 
code</span> 

  

<spaa aligns "left" class=> "InpuL_FieId"> 

<input type- "text" name- "inputZip" size- "5" maxleagth- "5" 
value- "602027> 
</span> 
<Avdkrwidget> 



their HTML representation. The widget library provides a 
level of abstraction between the user interaction component 
(e.g., a text input field) and its presentation (e.g., an HTML 
input field or a WML input field). This way the content 
producing model pages can be reused by different control 
files — one may deliver the content to a desktop browser 
using the HTML widget library, while another may deliver 
the same content to a handheld device using a modified 
version of the widget library (e.g., using WML). 

The widget library contains widgets for most commonly 
used inputs and controls, such as: 

Buttons and links: The link widget can be used to display 
an image button or regular hyperlink; 

List widgets: the list widget can be used to display 
common drop-down menus, set of radio boxes or set of 
check boxes; 

Input widgets for entering and displaying text values and 
passwords; 

Hidden variables: for storing values in the webpage 

without displaying them; 
Etc. 

An Example: wdk:input 

The wdkrinput widget represents the abstract notion of a 
text field. If the model page developer needs a text field to 



35 Note that the transformed version of the widget is 
"wrapped into w wdk:widget tags, this makes it very simple 
for the view transformation to reference the entire widget 
(e.g. by using <xsl:apply-templates select="wdk: widget 
[@name='inputZip']/>). Also note that the label and the 

40 field parts of the widget are wrapped in <span> tags with the 
class attribute set to InpuL_Label and Input__Field, respec- 
tively These class attributes can be used to customize the 
look and feel of the input widget by using Cascading 
Stylesheets (CSS) or by writing specific XSLT templates in 

45 the view transformation. For example, the following view 
transformation template will set all input labels in the page 
to use Arial font 



50 

<zsl:template match- "gpan[@class- 'Input_Lab«rj"> 
<span style- 44 font-family; Ariar> 

<xsl:apply- templates select- ~*"h> 
</sspan> 
</xsl:tcmplato 

55 

The wdk: input widget is implemented as XSLT templates 
as shown below: 



1 <xsl:template match="wdk input" > 

ocslrvariable name-"formElement"> 
<xsl:choose> 

<xsl:whcn test="booIcan(id)"> 

<xsl:va!ue-of select- u Dormalize-space(id)7> 
<tel:when> 
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<xsl "otherwise > 

<xsl:value-of select=**@name"/> 
</xsl:otherwise> 
</xsl:cbocse> 
</xslrvariable> 

2 <wdk:widget name-" {(©name }"> 

3 <span align="left" c lass «=»"In put Labcl**> 

4 <xsl:if test«"required= "TRUE"^ 

<xsl attribute namc- - styie">color:red</xsl :attributc> 

<xslrvalue-of select="label"/> 
<spaa> 
< 

5 <span align="lcft" class^Input, Field** > 

ocshchooso 

<xsl:when tcst^normalizc-spaccQjassword^a'tmc'^ 
<input name="{$formElement}" type="password"> 
<xsl real 1- template name="input_attributes'7> 
</input> 
<tel:when> 
<xsl:otherwise> 

<input namc-"{$fonnElcmcnt}"' typc»**texf '> 
<xsl:call- template name««**ii5Jut_attiibutcs , 7> 
</input> 
</xsl :otbxrwiso 
</xsl:cboose> 
<Jspaa> 

6 </wdk:widgct> 
</xslrtemplate> 

7 <xsl:template name="input_attributes"> 

otshif test-**boolean(sizc) M > 

<x$l:attribute namc="size**><xsl:value-of select»"normalize-space(size)"/><^sl:attribute> 
</xsl:if> 

<xsl:if test-"booleaa(inflxleiigth"> 

<xsl:attributc name="maxlcngth"><xsl rvalue-of scIcct"iK)r[mlize-spacc(max]ength)'V></x5l:attributc> 
</xsl:if> 

<xsl:if test-**boolean(vaIue) w > 

<xs I: attribute namc°"valuc"><xsl :valuc-of sclcct="nonnalize-spacc(valuc) , 7></xsl:attributc> 
</xsl:if> 
</xsl:template> 



Section 1 contains the match condition for the template: 
every wdk: input element in the document will be trans- 
formed using this template. In section 1 the name of the 40 
input field is computed as well. Section 2 shows that this 
widget Oust like all the other widgets) is nested inside a 
wdk: widget element, which makes it simpler to place wid- 
gets in the view transform. Section 3 shows how the 
different components (the label and the actual text field) are 45 
embedded in an HTML span element. In section 4 the color 
of the text label is determined based on the "required" 
sub-element of the wdk: input widget The logic in section 5 
determines what type of text field to generate: either "pass- 
word" or regular "text" field. Section 7 shows the template 50 
called from section 5 to fill in the attributes of the generated 
HTML input element. 

list of Widgets Defined in the wdk Widget Library 

wdk:hidden element: Represents an HTML hidden ele- 
ment. The widget generates the required element and Java- 55 
script functions that can be invoked to set the value of this 
element. 

wdk:form: Generates the HTML form element and Java- 
script functions needed to manage the form. 

wdk:input: Represents a single line text element. Can 60 
render the widget as a PASSWORD or TEXT HTML form 
field. 

wdk:list: Represents a widget for selecting an item from 
a set of predefined items. Supports four different HTML 
renderings: 6S 

Dropdown list 

list box 



Checkbox set 
Radiobutton set 

wdk:link: Represents a link or button. Besides submitting 
the form, the link widget can be used to: 

Pass parameters with the invoked URL using <field> sub 
elements; 

Execute an unlimited number of javascript functions 

before (or instead of submission; 
Open popup-windows and initialize the popup-window 

variables. 

Process the data returned by the popup window invoked 
by the link 
Commands 

Model pages are responsible for producing an XML 
representation of the content of the page. This content 
typically comes from executing complex business logic 
(e.g., running database queries, exercising business APIs, 
etc.). Although model pages (being XSP pages) are capable 
of including programming logic, including a large amount of 
code in an XSP page makes it hard to maintain. To solve this 
problem Web Content Server 800 introduces an implemen- 
tation of the Command pattern (Gamma et al.). A developer 
can invoke a command from a model page by using the 
execute Web Content Server 800 tag library tag. For 
example, the following line <wdktags:execute manager= 
"CatalogCommandMgr" command="search"/>invokes the 
execute method of the ICommand object registered under 
the "search" key of the CatalogCommandMgr and replaces 
the element with the XML result of executing the method. 
Here is the implementation of the wdkags: execute tag: 
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<?xml versions="l.(T?> 

<xsl:stylesheet version-"! .0" x ml ns:xsl="http:/Avww. w3.org/l999/XSL/Transform" 
xmlnsrxsp-" http://www.apache. org/1 999/XSP/Core" 
xmlns:wdtogs-"http://www.sabax^ 
<xsl:template namea"command_header"> 

<x6pstructore> 

<xsp :include>com.saba.xml. *</xsp:Lnclude> 
<zsp :include:>com .saba.web .dk. * </xsp:include> 

</xsp:stnicture> 

<xspJogio 

|Command cmd = mill; 

private | Command getCommand(String mngrName, String cmdName) 
throws Exception { 

Class mngrClass *» Class. forName(mngrName); 

|CommandManager mngr - (]ComrmndManager)mngrClas6.newInstance(); 
return and = mngr.getCommand(cmdName); 

} 

Node executeCommand(String mngrName, String cmdName, 
HttpScrvlctRcqucst request, HttpScrvlct Response response, 
Document document, Object argument) 
throws Exception { 

StringWriter writer - new StringWriterO; 
IXMLVisitor visitor = XMUgetDefaultXMLVlsitor(writer); 
. cmd - getCommand(mngrName > cmdName); 
if (argument !- null) 
cmd. execute (request, visitor, argument); 
else 

cmd.cxccute(request, visitor); 
String xml = writer.toStringO; 
if (xml.lengthO t= 0) { 

InputSource source - new InputSource(new String Reader (writer.toStringO)); 

XercesParser parser = new XercesPareerO; 

Document doc = parser, parse (source, false); 

return dcoimentimportNode^CKXgetFirstChildO, true); 

} 

else { 

return null; 

} 

} 

</xsp:logic> 
</xsl: tempi ato 

<xsl:template matcb=-**wdxiags:execute'*> 
<XBlrvariable name-"returnVariable> 
<xsl:choose> 

<xsl:when test=* , boolean(@ienirn)"><xsl:value-of select»"@return"/></xsl:when> 
<xsl:otherwise>wdkExecuteReturn<xsl.-value-o£ select-"generate-id()"/></xsl:otherwise> 
</xsl:choosc> 
</xsl:variabIe> 
<xsp:logio 

Node <xsl:value-of sclcct= u $rcturnVariablc"/>; 
</xsp:logic> 
<xspJogio { 

String wdkMngrName - "<x3l rvalue -of select-" manage r"/>"; 
String wdkCmdName » "<xsl:value-of select»"@command'7>"; 
Object wdkArgument = null; 
<xsl:if test»**boolcan(@argument)"> 

wdkArgument » (Object) <xsl:value-of select="argumenf*/>; 
</xsl:if> 

<xsl:value-of select-"$returnVariable"/> - (Nodc)executeCommflnd(wdkMngrName, 
wdkCmdName, request, response, document, wdkArgument); 
} 

</xsp:logtc> 

<xsp :expr><xsl :vaIue-of selea="$returnV^riable~/></xsp:expr> 
</xsl:template> 
</xslstylesheet> 



The stylesheet for the wdktags:execute contains two tem- 
plates. The first template (named command_header) is a 
template called by the main taglibrary stylesheet to create 60 
class level methods. These methods (getCommand and 
executeCommand) are called by the code that results from 
the transformation of the wdktags:execute tags. The get- 
Command method takes two arguments: the fully qualified 
name of a Command manager (see below) and a command 65 
name. It returns an I Command object (see below for details) 
that is registered with the command manager by the com- 



mand name. The executeCommand method performs the 
following steps: 

1. Creates an IXMLVisitor. It uses the default visitor 
provided by the XML class. 

2. Uses the getcommand method to get the command 
object 

3. Invokes the execute method on the command object. 
The created IXMLVisitor is passed to this method along 
with the request and argument objects that are passed to 
the executeCommand method. 
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4. The serialized XML document produced by the visitor 
object is parsed and the resulting DOM Node is 
returned. 

The template for the execute tag performs the following 
steps: 

1. Sets up a DOM Node variable for the node generated 
by the executeCommand method. 

2. Invokes the executeCommand method with the class- 
name of the command manager, the name of the 
command and the optional argument, and assignes the 
returned Node to the Node variable set up in step 1. 

3. Adds the generated Node to the document using 
<xsp:expr> tags. 

ICommandManager 

ICommandManager is the interface implemented by indi- 
vidual command managers. It declares the following 
method: 

public ICommand getCommand(String name) throws 
Exception; 

For convenience an abstract class implementing the 
ICommand is defined. 

This class provides the following API for its subclasses: 
public void regjsterCommand (String name, ICommand 
command); 

Command managers can extend this class and implement 
a single method: 
public abstract void initializeMapStructure( ) throws 
Exception; 

For example, the Domain command manager that man- 
ages commands related to security domains has the follow- 
ing implementation: 



IXML Visitor 



10 
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IXML Visitor declares the following methods: 

public void visit (String prefix, String tagName, String 
5 value) throws XMLVisitorException; 

public void visit (String prefix, String tagName, Number 

value) throws XMLVisitorException; 
public void visit (String prefix, String tagName, Locale 

value) throws XMLVisitorException; 
public void visit (String prefix, String tagName, Hm- 

eZone value) throws XMLVisitorException; 
public void visit (String prefix, String tagName, Date 
value) throws XMLVisitorException; 

public void visit (String prefix, String tagName, URL 

value) throws XMLVisitorException; 
public void visit (String prefix;String tagname, IXMLOb- 
ject value) throws XMLVisitorException; 
20 public void write OpenTag (String prefix, String tagname) 
throws XMLVisitorException; 
public void writeCloseTag (String prefix, String tagname) 
throws XMLVisitorException; 
25 public void createModel (String className) throws 
XMLVisitorException; 
Visit methods are declared for most frequently used data 
types and for IXMLObject. Besides the visit methods writ- 
e OpenTag and writeCloseTag are also declared. These two 
30 methods must be used when generating nested XML ele- 
ments. For example, take the following XML document 
fragment: 



public class DomaLaCommandManagcr extends 
AbstractCommandManager 
{ 

public DomaincommandManager 0 throws Saba Exception { 
superO; 

} 

public void initializeMapStructurcO 
throws Saba Exception 

{ 

rcgistcrCommancl("scarchFor Domain", new SearchCommandO); 
regi&terCommand("getDomainAndParents", new 
FarentsCommandQ); 

rcgistcrCommand( u cditDomain M , new EditCommandQ); 

} 

} 



50 

ICommand 

Command objects implement the ICommand interface. 

The ICommand interface follows the Command pattern (see 

Gamma et al., 1995) and the Prototype pattern. To support <doc> 

prototyping, ICommand extends the java Cloneable inter- <name>A name<namc> 

face. ICommand declares the following methods: 55 updated* 

& <person>Jill August</person> 

public void execute (HttpServletRequest req, IXMLVisi- <datc>i/i/2000<ydate> 

tor visitor) throws Exception; </updated> 

public void execute (HttpServletRequest req, IXMLVisi- ^ doc> 

tor visitor, Object arg) throws Exception 

These methods are invoked by the wdktags:execute tag in 60 A ^ pro duce this document fragment with the 

a model page. following sequence of visit calls: 
XML Serialization Framework 

Commands are used to generate an XML representation of 

some business objects. To make this task simpler, Web 

Content Server 800 introduces the notion of IXMLVlsitor 65 visitor.writcOpenTagfnull, "doc"); 

and IXMLObject following the Visitor pattern (see Gamma visitor. vi$it(null f "name", "A name"); 
et al, 1995.). 
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-continued 

visitor.writeOpcnTag(null, "updated"); 
visitor. visit(null, "person" "Jill August"); 
visitor. visit(null. "date" aDate); 
visitor.writeaoseTag(null ) "update'^; 
visitor.writeaoseTag(null, "doc"); 

Note: the prefix parameter for the visit, writeOpenTag and 
write CloscTag methods is used if the tags to generate arc in some specific 
namespace. (There is a separate namespace registration mechanism that 
associates the prefix with a particular namespace URLI). 



IXMLObject 

The IXMLObject interface declares the following meth- 
ods: 



- . — . . -public void acceptXMLVisitor (DCMLVisitor visitor) 
throws XMLVisitorException; 

public String getlhgName () ; 
Business object that implement the IXMLObject interface can be 
converted to XML by a command with a single method call: 

public void execute (HttpServletRequest req, DCMLVisitor 
visitor) throws Exception{ 
IXMLObject obj - getBusinessObject(req); 
visitor.visit(null, "theObject", obj); 
} 



In the above example the getBusinessObject(req) method 
call stands for some business logic that's used to create the 
business object (e.g. by using some of the business APIs). 

Interconnect Server 

The present invention provides a solution to the needs 
described above through a system and method for integrat- 
ing the disparate applications, and managing the applica- 
tions processes in a hardware resource and user effort 
efficient manner. The automated system of the present 
invention uses a business systems platform comprised of 
several unique servers to efficiently manage multiple appli- 
cations which are themselves generally distributed across a 
network, and to control the execution of the required tasks 
with minimum use of redundant data input to the several 
applications, thereby minimizing the use of hardware 
resources and user input effort. 

As indicated above, in a preferred embodiment, the Plat- 
form Interconnect Server allows a platform installation to 
interconnect with external systems. In the preferred 
embodiment, the Interconnect Server is a platform for infor- 
mation exchange based on XML and supports many types of 
information exchange across heterogeneous systems. Such 
heterogeneous systems could include Enterprise Resource 
Planning (ERP) systems, e-mail servers, and other Saba 
installations. The Interconnect Server allows interconnec- 
tion between such external systems and the Interface Server, 
Business Server, and Information Server. 

For example, this connection can be for purposes of 
importing data from ERP systems, exporting billing infor- 
mation to accounting systems, making catalog information 
available for automated search, or allowing automated pur- 
chasing of products. The Interconnect enables collaboration 
with the Platform network in a bi-directional fashion to 
allow a Platform-enabled site to share catalog information 
with the platform network, allow the platform network to 
place and track orders, and to share and update learner 
profiles. In addition, the process can be reversed: the 
platform-enabled site can enhance their internal offering of 
courses by including selected platform network courses in 
their internal catalog offering. 

Io the preferred embodiment, the Interconnect model 
consists of three parts: (1) the interconnect backbone and the 
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individual interconnect components installed on the inter- 
connect backbone (2) the development API's (both the 
high-level and the low level interfaces) and (3) the standard 
protocols used to communicate between heterogeneous sys- 
5 terns. 

Referring to FIG. 9, the Interconnect Backbone of the 
preferred embodiment is shown. The Interconnect Backbone 
is the framework that supports all Interconnect components. 
The Interconnect Backbone provides the foundation services 

10 required by higher-level services. These foundation services 
are always present, and include services for reliable 
messaging, service registration, monitoring and manage- 
ment. The Interconnect Backbone comprises the following 
components that provide the core Interconnect services: 

15 DeliveryService 905, ServiceManager 910, Locator 915, 
and Authenticator 920. The core Interconnect services are 
always present 

The Interconnect Backbone" provides' a framework for 
registering and resolving services. Services are registered 

20 and resolved by name in an interconnect node. The Service- 
Manager 910 is a core service for the management of 
services for the Interconnect at a particular location. The 
ServiceManager 910 tracks installed components, versions 
and system status. The ServiceManager 910 provides system 

25 management capabilities and can be queried for system 
status: which other components are present and whether they 
are currently running. Components, which implement Inter- 
connection Services 925, are installed on the Interconnect 
Backbone at a specific installation by being registered with 

30 the ServiceManager 910. The Locator 915 service is a 
service component that provides a way to register and 
resolve services by name. The Locator 915 services provides 
a flat registry of services at a particular interconnect loca- 
tion. 

35 The DeliveryService 905 is a service component that 
insures the reliable delivery of messages. The DeliverySer- 
vice 905 understands the sender, the recipient and quality of 
service, but not the content. DeliveryService 905 works over 
a variety of transport protocols by using different Delivery- 

40 Transports. Delivery Transports are abstract service compo- 
nents that are used by the DeliveryService 905 to reliably 
deliver messages over a particular set of network protocols. 
Such protocols include sockets, database logging tables, and 
HTTP. The messaging model provided by the DeliverySer- 

45 vice 905 provides a mechanism for the delivery of persistent 
asynchronous messages using a mailbox metaphor. Inter- 
connect Services 925 using the DeliveryService 905 register 
themselves and are assigned an Inbox by the DeliverySer- 
vice 905. Subsequently, the registered service may check for 

50 messages at that Inbox. The DeliveryService 905 component 
is described in further detail below. 

The Authenticator service insures that messages coming 
into the system have the appropriate credentials. Capabilities 
can be associated with a particular service and users can be 

55 assigned CapabilitySets. When a service is resolved, the 
Locator 915 calls the Authenticator 920 to validate that the 
requesting user has the appropriate capabilities to use the 
service they are requesting. A Capability is created for each 
named service in an interconnect location, for example 

60 "SAP/Financials/Accessor". Capabilities have names and in 
this case the name of the capability will be the same name 
as the service. Once created, Capabilities can then be given 
to users who want to access the service. When a message is 
constructed, the user adds their capabilities to the message. 

65 When the message is received by the target location the local 
DeliveryService 905 validates the capabilities with the 
Authenticator 920. The Authenticator service is the genera- 
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tor of capabilities and capability keys. If a passed in capa- 
bility doesn't have the appropriate key the capability is not 
set and the authentication is rejected. The service is also used 
by other core Interconnect Services for authenticating par- 
ticular application level requests. Since a capability is a 
name-key mapping, an interconnect service can create capa- 
bilities for any purpose desired. 

Other interconnect services are implemented like the core 
Interconnect Services described above. These Interconnect 
Services register and resolve by name and respond to and 
send Interconnect messages. Services are configured and 
managed using java classes and scripts. When interconnect 
components are installed on the Interconnect Backbone, a 
site is said to be "connector enabled". These components 
allow connections to external systems such as ERP systems 
to import, export, and synchronize data. 

Key to the Interconnect design is the separation of inter- 
face from implementation. Many of the service components 
are broken into a generic platform i independent portion and 
a platform specific portion that minimizes the impact of 
changes to the implementation in the future. Most connector 
components consist of a public service component (which is 
generic) and a service sub-component (which is system 
specific). The implementation of a connector in this frame- 
work consists of providing concrete implementations for the 
service sub-components and creating XSL stylesheets that 
describe mappings between a Local Format (LF) and Inter- 
change Format (IF). Local formats are system-specific rep- 
resentations of the data supported by a service, while Inter- 
change Formats are universal representations used for 
exchange between systems. 

Referring to FIG. 9, these Connectors services may 
include Monitor 945, Accessor 935, Importer 940, and 
Updater (not shown). Accessors, Importers, and Updaters 
are essentially thin wrappers around XSL stylesheet opera- 
tions. They translate documents between native formats and 
the Interchange format using a predefined stylesheet. These 
connector services may also contain additional logic for 
cases where a single Interchange format document repre- 
sents multiple native documents, and vice versa. A more 
detailed description of the service components for these 
Connector services and their implementation on the Inter- 
connect Backbone follows. 

The Accessor 935 is a public service component that is 
used to extract objects from the source representation and 
convert them to a Interchange Format (IF). An Accessor 935 
is configured to use a particular AccessorReader 950 to 
extract the objects from the source system and collaborate 
with Translators to perform the conversion to IF. The Acces- 
sorReader 950 is an abstract service sub-component that is 
used by an Accessor 935 to extract an object, or set of 
objects from a source system and convert them into an 
Interchange Format. Concrete implementations of the 
AccessorReader 950 are system specific and use the native 
API of the source system. 

The Importer 940 is a public service component that is 
used to import objects from Interchange Format to the target 
representation. An Importer 940 will collaborate with Trans- 
lators to perform the conversion from IF and be configured 
to use a particular ImporterWriter 960 to inject the objects 
into the target system. The ImporterWriter 960 is an abstract 
service sub-component that is used by an Importer 940 to 
convert an object, or set of objects into a Local Format (LF) 
and write them to a source system. Concrete implementa- 
tions of the ImporterWriter 960 are system specific and use 
the native API of the target system. 

The Monitor 945 is a public service component that 
monitors changes to local objects and reports changes to 
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interested parties in Interchange Format. Clients can register 
to receive notification of the change only, or have the 
changed object sent with the notification. A Monitor 945 is 
configured to use a particular ChangeManager 955 to map 

5 changes in the source system to a standard event format that 
the monitor can use. The ChangeManager 955 is an abstract 
service sub-component that is used by a Monitor 945 to map 
local events into the standard event format. Concrete imple- 
mentations of the ChangeManager 955 are system specific 

10 and use the native API of the source system to capture 
events. 

When the Monitor 945 receives an event from the 
ChangeManager 955, it checks to see if the object needs to 
be sent with the notification. If so, the Monitor 945 will 
15 collaborate with the Accessor 935 and Mapper to provide the 
conversion from source object to Interchange Format. The 
Monitor 945 uses the Mapper to find the platform ID 
associated with the local identifier in the event. This' plat- 
form ID is then used to request the object from the Accessor 
20 935. The Mapper is a utility that provides object and class 
level mapping services between representations, each con- 
nector framework contains a single instance of the Mapper. 
The Mapper data is persistent this enables the cross refer- 
ence data to survive restarts. The Mapper maintains maps for 
25 (1) Platform ID to Document Type, (2) Local ID to Platform 
ID, and (3) Platform (Interconnect) user to Local (mapped 
system) user. The Mapper (discussed in detail in a later 
section )converts a local object Id (a combination of Id and 
Class type ) into a Platform Object Id (POID ), POID is an 
30 Id that is unique across applications. POID is a serializable 
class that has URL representation 

u http:/r+hostVVinterconnect/ , '+platform+"/ , '+seqNo 
where host-»is the hostname of the machine on which the 
connector is running 
35 platform-»a parameter defined at the Saba site level. 

This parameter will make the POID unique if mul- 
tiple Saba sites are running on the same machine. 
SeqNo— *is a sequence number that that is unique for a 
host. 

40 Example of a POID is 

http://jade/interconnect/Saba/l this could be a represen- 
tation of local id emploOOOOOOOOOOOlOOO with class type 
com.saba.busobj.SabaEmployee. This representation can be 
converted to instance of POID by using static method in the 
45 POID class. 

POID class definition is 



50 public class POID implements DCMLRenderable 
{ 

private GenericObjectID mLocaUD; 
private URL mURL; 
private long mid; 

public POID (GenericObjectID locallD) { 
55 mid- getNextldQ; 

try 
{ 

mLocaUD - locallD; 

mURL = new URL(gctURLPrefix( ) + localID.toString( ) + 
T + mid); 

60 catch (MalfarmedURLException x) 

{ 
} 

} 

public void setLocalID(GenericObjectID locallD) { 
try { 

65 mLocaUD - locallD; 

mURL - new URL (getURLPrefix( ) + localIDtoString( ) + 
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-continued 



r + mid); 
} 

catch (MalfonnedURLException x) { 

if (mid — -1) 
{ 

mid - getNextId( ); 

} 

} 

public String toString( ) 

return mURLtoString( ); 

public URL gctURLO 
{ 

return mURL; 

} 

public GencricObjectlD getLocalID() 
return mLocallD; 

} 

public static POID getPOID(String url) 
{ 

String temp-new String(url); 
int po3»temp JasttndexOf( a r); 
String templ=<emp.substriiig(pos+l); 
Long temp2=Long,valueOf( tempi); 
long hash-temp2 . long\feluc( ); 
POID poid-ncw POID( ); 
poid . mld=hash; 
try{ 

poid.mURL=new URL(url); 

} 

catch(MalformedURLException x) 

{ 

} 

return poid; 

} 



Mapper stores the cross reference between the local Id 
and the POID representation of the local Id. The Mapper also 
stores cross reference between foreign POID and local Id in 
the case where the Object originated from a foreign system. 

A Transformer is a utility that provides translation ser- 
vices between representations using mapping data and XSL 
style sheets. A Transformer wraps a particular XML parser 
and XSL translator. The Accessor calls an implementation of 
the transformer and passes the Local Format and the 
stylesheet, the transformer translates the Local Format into 
Interchange Format. 

Implementing a connector involves building four plat- 
form specific components and defining a set of document, 
object and user mappings. The platform specific components 
are described in detail below and include the (1) Change- 
Manager 955 (maps system events to Monitor 945 events), 
(2) AccessorReader 950 (extracts objects from the system in 
XML format), (3) ImporterWriter 960 (injects objects into 
the system from XML format), and (4) LocalObjectID 
(Encapsulates the system object identifier, this is not 
required if the system can use the GenericObjectID 
available). Additionally,, the types of documents to be 
exchanged need to be defined. Once these are determined 
and their format defined, XSL style sheets need to be written 
which convert Interchange Format to the system specific 
XML format and vice versa. 

At system deployment time, a number of mappings need 
to be defined These include (1) Document type to style 
sheet, (2) local User to system user, and (3) the Translator 
the connector will use. 

The ChangeManager 955 sub-component monitors the 
native system for all events such as Insert/Update/Delete on 
objects. It can interact with the event notification mechanism 
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of the native system to capture all the events and then pass 
these events to the monitor for further handling. The 
ChangeManager 955 accepts events from the native system, 
converts these events into MonitorEvent Objects, and for- 

5 wards these to the Monitor 945 using the method 
IChangeManagerAdaptor.notify( ) method. Once the 
Change Manager passes an event on to the Monitor 945, it 
is then the responsibility of the Monitor 945 to reliably 
deliver the request on to any subscribers who have registered 

10 interest. The Monitor 945 will filter out any events that are 
not subscribed to. Specifically, the Change Manager is 
responsible for (1) keeping track of all the events that take 
place in the native system, (2) creating MonitorEvent 
Objects for all events supported by the native change 

15 management, (3) Calling the notify method of the Monitor 
with a given event. 

ChangeManager 955 requires a reference to its owning 

. Monitor 945 class.to invoke its.notify( ) event. It also needs 
a LocalUser object to obtain credential information. These 

20 references are provided during construction. 



public abstract class ChangeManager throws 
connectorException 
25 { 

public ChangeManager (Monitor theMoaitor, UserObjcct 
user) 

public void shutdown( ) 



As mentioned above, the ChangeManager 955 coverts 
each system event into a MonitorEvent object, which it 
passes on to the monitor by calling its notify method. The 
Monitor Event class is as follows: 

35 



public class MonitorEvent { 

public Object objectlD; 
public String eventType; 
public String docl^pe; 
public Boolean applyStyteSheet; 
} 



The Monitor is responsible for implementing the interface 
IChangeManagerAdaptor which currently defines a single 
method. 



public interface I Change ManagerAdapter { 
50 public void notify(MonitorEvent event); 



The ChangeManager.shutdown( ) method is invoked by 
the Monitor 945 and is used to gracefully disconnect the 

55 ChangeManager 955. When shutdown( ) is called, the 
ChangeManager 955 is responsible for closing any open 
connections, unregistering itself from the native event sys- 
tem and taking any other action required to perform a clean 
shutdown. The ChangeManager 955 can shut down itself if 

60 required by using this method. 

The AccessorReader 950 is a platform specific sub- 
component of the Accessor 935. It is responsible for extract- 
ing an object from the native system in a convenient XML 
representation. The representation produced must be com- 

65 plete enough to allow it to be transformed into the appro- 
priate document in Interchange Format. An instance of an 
AccessorReader 950 will service the requests of a particular 
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user. When an AccessorReader 950 is created a UserObject 
that identifies the system user is passed to it in its construc- 
tor. The AccessorReader 950 is responsible for making 
managing a connection to the native system on behalf of this 
user. The Accessor 935 is responsible for making sure that 
incoming requests are assigned to the appropriate Accessor- 
Reader 950 for the requesting user. The AccessorReader 
calls the Mapper to get the Platform Id (POID ) for the local 
Id representation, the local Id representation is replaced with 
the POID. 

An implementation of an AccessorReader 950 will be 
derived from the abstract class of the same name: 



"" public AccessOTRcad«(UseiObiject user); 



public abstract class AccessorReader implements 
IAccessorReader 

J. 
} 

public interface IAccessorReader { 

public Reader extractObjectRcadcrfObject locallD) 

throws lOException, ConnectorExccption; 
public URL extractObjectURL(Object locallD) 
throws MalfonnedURLException, 
OonnectoiExccption; 
public void $hutdown( ); 



20 



25 



Specifically, the AccessorReader 950 is responsible for 
(1) Establishing a connection into the system based on the 
User Id and Credentials (2) Extracting the required object 
based on the information passed in Local Object (3) Trans- 
forming that Object into a serialized representation, which is 
an XML document (4) If the object type of the local object 
maps to more than one object in native system, then extract- 
ing all the corresponding objects in the current context, (5) 
As the objects to be transported to and from the native 
system are known, information about which objects have to 
be extracted for a given object can be maintained specifi- 
cally for the current implementation, (6) Serializing this 
localObject/s into a single Local XML representation (7) 
Returning this XML document back to the Accessor 935, (8) 
Providing a clean shutdown by closing the connection. The 
shutdown method is invoked by the Accessor 935 when it 
needs to shutdown the AccessorReader 950. 

The ImporterWriter 960 is a platform specific sub- 
component of the Importer 940. It is responsible importing 
an object into the native system from a convenient XML 
representation. The representation must be able to be pro- 
duced from a document in Interchange Format using XSL 
style sheet transformations. Like the AccessorReader 950, 
an instance of an ImporterWriter 960 will service the 
requests of a particular user. Once an Object has been 
imported the newly created local Id and the Foreign POID 
sent along with the Interchange format are inserted into the 
Mapper for subsequent use. Mapper is discussed in detail in 
a later section. 

An implementation of an ImporterWriter 960 will be 
derived from the abstract class of the same name: 



public abstract class [mporterWriter implements 
IloiporterWriter { 
Object mUser, 

public ImporterWriter (UserObject user) 

{ 

mUser ■» user; 
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public interface [ImporterWriter { 

r m 

Insert the Objects from the input stream and return 
an array of native (local) identifiers for the new 
objects. The input stream is in a localized XML 
format. 

V 

public Object insertObjectFromStreamfWriter in) 

throws ConnectorException; 
A" 

Insert the objects from the URL and return an array 
of native (local) identifiers for the new objects. 
The input URL is in a localized XML format. 

V 

public Object insertObjectFromURL(URL url) 

throws MalformedURLExccption, ConnectorExccption; 
public void shutdown( ); 



} 



The ImporterWriter 960 is responsible for (1) Establish- 
ing a connection into the system based on the User Id and 
Credentials (2) Mapping the single XML document received 
to one or more objects required to be inserted into the native 
system (3) Converting the Native XML representation of the 
object into native system specific format (4) Based on the 
event to be performed, insert, update or delete the database 
(5) In case of a new object being inserted, returning the local 
identifier for the object inserted (6) Providing a clean 
shutdown by closing the connection. The Importer 940 
invokes the shutdown method when it needs to shutdown the 
ImporterWriter 960. 

The UserObject encapsulates system specific User infor- 
mation for an application level login (user id and password). 
The platform specific parts of the connector services will use 
this information to log into the target system. For example 
a ChangeManager 955 may need to login to the database to 
trap the events. The UserObject object encapsulates a string- 
based userid and the notion of Credentials. Each Platform 
implementation provides its own LocalUser object. Imple- 
mentations provide a subclass of the credentials Object 
customized for the security requirements of their system; in 
the simplest case the credentials are a String password. 



public class UserObject implements Serializable 



{ 



50 



55 



String mUsemame; 
Object mCredentials; 

public UserObject (String useraame, Object credentials) 

mUsemame « username; 
mCredentials - credentials; 

} 

public String getUsemame( ) 
} 

public Object getCredentials( ) 



return mUsemame; 



{ 



return mCredentials; 



60 



} 



The Local object contains information about the object 
that the connector uses uniquely identify an object in the 
65 native system. It holds the following information about the 
object (1) ID: An opaque object identifier, and (2) aClass: the 
type or class of the object. 
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The LocalObjectID class is defined as: 



public class LocalObjectID 
{ 

Object mID; 
Object mClass; 

public LocalObjectID (Object ID, Object aClass) 
{ 

mID - IL> 

mClass - aclass; 

} 

public Object getlD() 
{ 

return mID; 

} 

public Object getObjectClass( ) 



{ 



return mQass; 



10 
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delivered from a Source site 1000 to a target SAP system 
1005 utilizing the Interconnect Server 1010 is set forth. An 
Importer component 1015 resides on the target SAP system 
and the Requestor 1020, Monitor 1025, Event Manager 
1030, Accessor 1035, and Transformer 1040 components 
reside on the Interconnect Server 1010. At step 1, At the 
Source site 1000, a Purchase order 1045 is generated and a 
"Sabalnvoice" object is created. At step 2, the Purchase 
Order 1045 is saved. Because it needs to be synchronized 
with a remote system, this triggers a pre -registered Change- 
Manager event at the EventManager 1030. At step 3, the 
ChangeManager passes the unique id of the Sabalnvoice to 
the Monitor 1025. At step 4, the Monitor 1025 instructs the 
Accessor 1035 to retrieve the SabaOrder in Interchange 
Format. At step 5, the Accessor 1035 retrieves the Sabaln- 
voice in serialized, canonical XML format This is an 
internal XML format that varies for each business object. Its- 
essential feature is that it contains all relevant information 
about the PO in attribute/value format. Step 5 uses a 
standard method available for all SabaObjects. 



Referring to FIG. 10, an example of the operation of the 
above Interconnect services in which a purchase order is 



The following example Local Format document is a 
sample Sabalnvoice serialized into XML 



<?xml version-" 1.0" Btandalone-"yes"?> 
<SabaObjcctSerialization Mnlri3:dt-' t iimrw3-org3Qnldatatypc3"> 
<SabaObject type»"conxsaba.busobj.SabaInvoice" id="invce000000000001000" 
status="new"> 

<amL_paid dl:typc- M numbcr">0.0<^amt_paid> 
<other__charges dt:type«"number">0.0</other_charges> 
<acct_id 

idref-" http ://spanuganti/i nterconnect/Snba/com.saba.int^^ 67> 
<updated_by dt:type="string">uone</updaied_by> 
<balance dt:type»" number" >425.0</batance> 

<updated_on dt:type-"dateTune">2000-ll-10 19:17:40.000</updated_on> 

,<crcatcd_by dt:typc="string">uonc</created_by> 

<created_id 

idref-"http 7/spanugantiAnterconnect/Saba/coni.8abaintercoQnecL ObjectID@170064/6"/> 
<inv_date dt:typc="datcTimc">2000-ll-10 19:17 :40.000 </in v_datc> 
<created_on dt:type="dateTime">2000-ll-10 19:1 7:40. 000</created_on> 
<split dt:type-"string">domin0000 0000 00 00001 </split> 
<statua dktype» M numbei">100<Matiis> 

<iime_stainp dt:type»"stringf*>200011101917399262</time_stamp> 
<flags dt:type-"string''>0000O00O00</fiags> 
<iiivoicc_no dt:typc=-"5tring">O01000</LQvoicc __no> 
<cuiTeiicy_id 
idref-"http7/spanuganti/intercmnect/Saba/<» 

<total_chargcs dt:type="number">425.0</totaL_chargcs> 
</SabaObject> 

<SabaObject type-"com.saba.busobj.SabaInvoiceItem" id- - invit000000000001000" 
status-" qcw"> 

<order_Jteux_id idief="ordit0OD000000O01060"/> 
<invoice„id 
idref-"http://bncmazie/totercoimect/^ 

<time_stamp dt:type-"string">20001 110191 740 6145 </time_jtamp> 
</SabaObject> 

<SabaObject type-"com.saba.busobj.SabaOrder" id-"cxtor000000000001040" 
status="ncw"> 

ocity dt:type="string''>Sunnyvale<Vcity> 
<addrl d^type-^tring^Addr lWaddrl> 
flcountry dt:type="string">US</country> 
<shipped_amt dt:typeo"number">0.0</shipped_amt> 
<state dt:type-"string">CA^state> 
<discount dt:type«"number">0.0<discount> 
<updated_by dt:type»"string">UONE<Aipdated_by> 
<order_no dt:type-"stiing">001040>/ordcr_QO> 

<updated_on dt:type="dateTlme">2OOO-ll-10 19:13:19.000<AipdatedL_on> 

<created_by dt:type=**string">uone</created_by> 

<crcated_id 

idrefw"http ://spanuganti/i nterconnect/Saba/co rDusaba.intcrcoatiect.ObjectID@170064/6'7> 
<sbipped__attn dt:type-"string">testl testl<&hipped_atta> 
<contact_Jd 
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idief-" http ^/bnemazie/inteiconncct/Saba/com^aba. in terconnectObjcctID@c9 16281 1/1 7> 
<neated_on dtAype="dateTiine">2000-ll-10 19:13:39.000<taeated_on:> 
<sold_by_id 

idref«"http y/Sspanuganti/intercc nnectySaba/com. saba. interconnea.ObjectID@170064/6"/> 
<split dt:typc="string">dominOOOOOO 00000 0001 </split> 
otatus dt:type-"number">4(XWstatus> 

<timc_stamp dttypc="string">20001 11 01917406145<ytimc_stamp> 
<company_Jd 

idref-^ht^) ^/spanuganti/interconnect/Saba/com. saba. interconnect.Objectf D@94902deb/206"/> 
<territory_id idre^nerriOOOOOOOOOOOOOOl"^ 
<conf_type dt:type="number">0</conf_type> 
<zip dt:type-"string">94086^/zip> 
<account_id 

idref«"latp^/spanuganti/interconnecl/Saba/com.saba. interconnecLObjectID@94902deb/20 <S*7> 

<currency__id 
idref- M http;/^panuganti/intercomea*/Sab^ 

<status_flag dt:type="string">200020CXX)0</stfltns_Jiag> 

<total_chaiges dt:type-"number">425.0</total_charges> 

<chfldrch> * ' . . 

<SabaObject type="com.saba.busobj.SabaOrderIlem" id=>"orditO0 0000 000001061" 
8tatus-"new"> 

<order_id idref»"extorO00O0CXX)0001040"/> 
<unit_cost dt:typc-"numbcr">425.0</uiiit_cost> 
cdescription di:type»^tring">Inventoryl<Mescription> 
<actual_qty dt:type-"numbei">l >/actual_qty> 
<part_id idicf=^idct0000000000010227> 
<pkg_item id idref^orditOOOOOOOOOOOlOSl"^ 

<creatcd_on dt*ype= - dateTime w >2000-ll-10 3 9:1 3:28.000 Vcrcated_on> 
<req_qty dt:type»"numb«">l<yrcq_qty> 

<dclivcrcd_on dt:type» < *datcTunc >, >2000-ll-10 19:17:13.000</dclivcred_oa> 
<status dt^ype="number">300</Status> 

<timc_atamp dt:typc-"string">200011101917406145Vtimc__stamp> 
<OistomO dt:^pe="string">Billed</CustomO> 
<flags d t:type-"string">000 0000000 </flags> 
<total_cost dtlypc="number">42S.0</total_cosl> 
<iten\_typ dt:type-"oumbei">l </item_typ> 
<billing_statc dt^ype="numbei">101</billing_state> 
<SabaObject> 

<SabaObjcct typc="com.saba.busobj.SabaOrdcrftem" id="ordit000000000001060" 
status— "new"> 

<ordcr_id idref="«tor000000000001040*7> 
<unit_cost dt:type=» 44 number">0.0<Ainit_cost> 
^description dktype»*^tring">Dcfault Dcfeult<ydcscription> 
<actual_qty dt:type="'number">l</actual_qty> 
<part_id idrcf="shpnid0O0O000000Q00017> 
<pkg_itcm_Jd idief-"ordii0000000000010607> 

<crcatcd_on di:type-Matelimc">2000-ll-10 39:13:27.000^crcated_on> 
<req_qty dt:type="tiumbef '>l</rcq_qty> 

<deIivercd_on dt:typc-"datc , nmc">2000-ll-10 19:17:13.000</dclivcred_on> 
cstatus dt:type="number">300</scatii5> 

<timc_8tamp dt:type-"string ,, >200011101917406145«</time_stamp> 

<Custom0 dt:typc=* i string">Billed</CustomO> 

<flags dt:type-"Btring*'>O0OO0OO0O0^flags> 

<total_cost dt:type="number'VO.O<Aotal_cost> 

<item_typ dt:type-"number">6</item typ> 

<billing_^statc dt;typc="numbci">101</billing_statc> 
</SabaObject> 
</childrca> 
</SabaObject> 

<SabaObjcct typc= M com.saba,busobj.SabaInvoiccItcm" id="invit000000000001001" 
status«»"new"> 

<ordcr_itcm_id idrcf-"ordit0000000000010617> 
<dnvoice_id 
idrcf-"http://bncmazWintercoimec^ 

<tune_ J stamp dutype«* 4 striiig**>200011 1019 174061 45 </time_stamp> 
<cfSabaObject> 
</SabaObjectSerialization> 



At step 6, the Accessor 1035 then transforms the XML 
document into an Interchange document format. The Acces- 
sor 1035 accomplishes this by passing the source document 
and an XSL stylesheet to the Transformer 1040. 

The following is a sample purchase order XSL stylesheet: 
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<?l-COPYRIGHT NOTICE Copyright (c) 1997-2000 Saba Software Inc., 2400 Bridge 
Parkway, Redwood Shores, California 94065-1166 USA. All rights rcserved.-> 
<xsl:stylesheet xmlns:xsl- w http:/Avww. w3.org/1999/XSL/Transform"> 
<xsl:output omit-xml-declaration="no"indent-"yes" method="xml"/> 
<xsl:template match="SabaObjectSerializatioD"> 
<SYNC_INVOICE_001 > 
<CNTROLAREA> 
<BSR> 
<VERB>SYNC</VERB> 
<NOUN>INVOICE</NOUN> 
<REVISION>001 </REVIS[ON> 
<^BSR> 
cSENDER> 

<LOGICALID/> 

<COMPONENT/> 

<TASK/> 

<REFERENCEID/> 
<CONFIRMAT10N/> 

" ' <LANGUAGE/> " "* ' ' * 

<CODEPAGE/> 
<AUTHID> 

<xsl rvalue- of sclect-"crcated__by7> 
</AUTHID> 
</SENPER> 

<DATETTME quaKficr- 44 CREATION"> 
<YEAR> 

<Jtsl.*vahie-of select= tt substring(//created_on,7,4)'7> 
</YEAR> 
<MONTH> 

<xsl:vahie-of select»**substring^/created_on,l > 2)"/> 

</Monm> 

<DAY> 

<xs) rvalue- of selecU M substring(//created_on,4^)"/> 

<DAY> 

<HOUR/> 

<MINUTE/> 

<SECOND/> 

<SUBSECOND/> 

<TTMEZONE/> 
</DATETIME> 
<CNTROLAREA> 
<£)ATAAREA> 

<xsl: for-each select-"//SabaObject[<^ype-'coirLSaba.rjiisobj.SabaInvoice7V 
<1NV0ICE> 
<INVDATE> 

ocsbvalue-of select 4 7/inv_date7> 
</TNVDATE> 
<CURRENCYID> 

<Ksl:value-of se 1 ect="//cwr ency_id/@idre f/> 
</CURRENCYID> 
<INVNO> 

<xsl:value-of select-7/invoioe_Bo7> 
<INVNO> 
<INVOICEID> 

<xsl:value-of select="@id7> 
<tfINVOICEID> 
<TOTALCHARGES> 

<xsI:value-of select=**//total_charges"/> 
</TOTALCHARGES> 
<ACCITD> 

«csl:value-of select="acct_id/@idref7> 
</ACCUD> 
<CREATEDn>> 

<xsl:value-of select= M created_id/@idref 7> 
</CREATEDID> 
<TJPDATEDON> 

ocsl:value-of select="updated_on7> 
</UPDATEDON> 
<ORDERID> 

ocslrvalue-of select="order_Jd/@idref7:> 
</ORDERID> 
<BALANCE> 

<xsl:value-of select="balance'7> 
</BALANCE> 
<AMTPAID> 

ocsl:value-of select*»"amt_paid'7> 
</AMTPAID> 
cOTHERCHARGES> 

<xsl:value-of select»"other_charges7> 
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<^OTHERCHARGES> 
<STATUS> 

<xsl:value-of select-"status'7> 
</STATUS> 
<FLAGS> 

<xsl:value-of select-"flagp"/> 
</FLAGS> 
<SPUT> 

<xsl:value-of select-"split"/> 
<SPLIT> 
<POID> 

<xsl:value-of select-"poid/@idref 7> 
</POlD> 

<REMINVDATE/> 
<REMINVID/> 
<tfNVOICE> 
</xsl:for-each> 

<xsl:for-each seIect- M //SabaObject(@type»'com.saba.busobj.SabaInvoiceItein'J'> 
<xsl variable namc="ORDERrrEMID"> '* 

<xsI:value-of sclect="ordcr_itcm_Jd/@idrcf 7> 
</xsl:variable> 

<xsl:for-each sclcct» w //SabaObjccl{@typc-'com.saba.busobj.SabaOrdcrItcin']"> 
<xsl:if test="$ORDERITEMID@id"> 
<ITEM> 
<ACCTID> 
<xsl:value-of select="//account_jd/@idref 7> 

«VACcm>> 

<T0TALCOST> 

<xsl:value-of sclcct="totaL_oost*7> 
</TOTALCOST> 
<DESCRIPTN> 

<xsI:value-of select« M description7> 
</DESCRIPTN> 
<UMTCOST> 

<xsl:valuc-of selcct»**uniL_cosf7> 
</UNITCOST> 
<ACTUALQTY> 

<xsl:vaIuc-of sclcct="actual_qty"/> 
</ACrUALQTY> 
<UNEID> 
oal:valuc-of sclcct» M @id'7> 
</UNElD> 
<ATTRIBUTE1> 

<xsl:va!uc-of sclcct= M @id"/> 
</ATTRIBUTEl> 

ocslrva liable Qame-"STUDENTID"> 

<xslrvaluc-of sclcct="studcnt_id/@idrcf 7> 
<tfxsl:variable> 

<xsl :for-each select-**//SabaObject[@id-$STUDENTID J*> 
ocshvariable name="STUDENTNAME"> 
<xsl:value-of select="laamc*7>,<xsl:value-of 
select-* 1 &iame'7> > Phoiie : ocst gallic -of select-"woikphone"/> 
</xsl:variablc> 
<ATTRIBUTE2> 
<xsl:value-of seIect="$STUDENTNAME7> 
<ATTRIBUTE2> 
</xsl:for-each> 
</TTEM> 

</xsl:for-cach> 
•acsl:for-each> 

<xsl:for-each seIect="//SabaObject[@type= , com.saba.busobj.SabaInvoice , J'> 
<USERAREA> 
<OBJSTATUS> 

<xs!:vnluc-of sclect="@status'7> 
</OBJSTATUS> 
<0BJTYPE> 

ocsl:value-of sclect="@type*7> 
</OBJTYPE> 

<AMOUNT_INCUJDES_TAX_FLAG>N</AMOUNT^NCLUDES_TAX_J r LAG> 
<USERAREA> 
</xsl:for-eacb> 
VDATAAREA> 
<SYNC_INVOICE_001 > 
</xsl:template> 
<xsl:stytesheet> 
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The following is the equivalent Interchange Format docu- 
ment generated by the stylesheet transformation, an Invoice 
in OAG BOD format. 



<SYNC_INVOICE_001 > 

<CNTROLAREA> 

<BSR> 

<VERB>SYNC</VERB> 

<NOUN>INVOICE</NOUN> 

<REVISION>O01<yREVTSION> 

</BSR> 

<SENDER> 

<LOGICALID/> 

<COMPONENT/> 

<TASK/> 

<REFERENCEID/> 

^CONFIRMATIONS 

<LANGUAGE/> 

<CODEPAGE/> 

<AUTHID/> 

</SENDER> 

<DATETIME qualificr-"CREATION"> 

<YEAR>1-10</YEAR> 

<MONTH>20</MONTH> 

<DAY>0-</DAY> 

<HOUR/> 

<MINUTE/> 

<SECOND/> 

<SUBSECOND/> 

<TIMEZONE/> 

</DATETIME> 

</CNTROLAREA> 

<DATAAREA> 

<INVOICE> 

<INVDATE>200(M1-10 19:17:40.000</INVDATE> 
<CURRENCTID>hitp://spanuganti/inte^ 
ObjccUD@14966/34<^CURRENCYID> 
<INVNO>001000^NVNO> 

<INVOICEID>iiivoc000000000001000<^NVOICEID> 

<TOTALCHARGES>425.0</rOTALCHARGES> 

<ACCnD>http ^/spanuganti/intcrooimcct/Saba/coiiLsaba.iiitcrco onccL 

ObjectID@94902dcb/206</ACr*nD> 

<CREAIBDII>>http://spanugantiAaterco 

ObjcctrX)@170064/6^CREATEDID> 

<UPDATEDON>2000-11-10 19:17:40.000</UPDATEDON> 

<ORDERID/> 

<BALANCE>425.0</BA1ANCE> 

<AMITAID>0.0 </AMTPAID> 

<OTHERCHARGES>0.0</OTHERCHARGES> 

<STATUS>100</STATUS> 

<FLAGS>O0OO00000C</FLAGS> 

<SPLJT>domiii000000000000001</SPLIT> 

<POID/> 

<REMINVDATE/> 
<REMINVID/> 
</INVOICE> 
<ITEM> 

<ACCTH>>http://spaauganti/interro^ 

ObjcctID@94902deb/206^/AOCTID> 

<TOTALCOST>0 .0</TOTALCOST> 

<DESCRIPTN>Defauk Default </DESCRIPTN> 

<UNITCOST>0.0</UNITCOST> 

<ACTUAL0TY>1 </ACTU ALQTY> 

<UNEID>ordit000000000O01060</UNEID> 

<ATTRIBUTEl>ordit000000000001060</ATTRIBUTEl> 

</ITEM> 

<ITEM> 

<ACCllU>bttp^/spanuganti/interooimect/Saba/com.5aba.interco^ 

Object£D@94902dcb/206</AOCTID> 

<TOTALCOST>425 .0</TOTALCOST> 

<DESCRIPTN>Invcntoryl</DESCRIPTN> 

<UNlTCOST>425.0</UNrrCOST> 

<ACTU AL0TY>1 </ACTUAJjQTY> 

<UNEID>ordit000000000001061</UNEtD> . 

<ATTRIBUTEl>ordkOOO(K)0000001061</ ATTRIBUTED 

</TTEM> 

<USERAREA> 

<OBJSTATUS>ncw</OBJSTATUS> 
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<OBrrYPE>com.saba.busobj.SateInvoicc</OBITYPE> 

<AMOUNT_INCLUDES_TAX_F1j\G>N</AMOUOT_[NCLUDES_TAX__FLAG> ' 

</USERAREA> 

</DATAAREA> 

</SYNC_INVOICE_001 > 



At step 7, the Monitor 1025 receives the Interchange 
Format document back from the Accessor 1035. At step 8, 
the Monitor 1025 instructs the Requestor 1020 to deliver the 
Invoice to the SAP system. At step 9, the Process Invoice 
document is actually delivered over the network to the SAP 
system. The Requestor 1020 reliably ensuring that the 
Invoice is actually delivered and received. At step 10, the 
Process Invoice document is inserted into the SAP system as 
a new Invoice. Step 10 is performed by the SAP Importer. 
There are several possibilities for the implementation of the 
SAP Importer, depending on the level of functionality pro- 
vided by SAP: (1) SAP supports the Interchange Document 
format directly, in which case this step is trivial, or (2) SAP 
supports a proprietary XML format, in which case a 
stylesheet can be used to transform the Invoice into SAP's 
proprietary format, or (3) SAP supports a proprietary API, 
which is used to read and process the XML document, either 
in its original format or after a stylesheet transformation into 
a more convenient format. 

As another example, an employee record maintained in an 
external system is reflected in a SABA site. An administrator 
registers a callback event with an Interconnect enabled 
human resources (HR) system. A change in the HR system 
generates an event that is captured by the external system 
Monitor. The Monitor requests the HR data from the Acces- 
sor. The external system Accessor generates the updated HR 
record as an Interchange Document. The following is 
another example Interchange Format document, a Sync 
Personnel BOD: 
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<SYNC_EMPLOYEE_001> 

<CNTROLAREA> 

<BSR> 

<VERB>SYNC</VERB> 

<NOUN>EMPLOYEE</NOUN> 

<REVISION>001 <mEVTSION> 

</BSR> 

<SENDER> 

<LOGICALID/> 

<COMPONEINrr/> 

<TASK/> 

<REFERENCEID/> 

<CONFIRMATION/> 

<l^NGUAGE/> 

<CODEPAGE/> 

<AUTHID/> 

</SENDER> 

<DATETIME qualifici*-"CREATION"> 

<YEAR/> 

<MONTH/> 

<DAY/> 

<HOUR/> 

<MINUTE/> 

<SECOND/> 

<SUBSECOND/> 

<TI MEZON E/> 

</DATETIME> 

</CNTROLAREA> 

<DATAAREA> 

<SYNC_EMPLOYEE> 

<EMPLOYEE> 
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35 



<NAME mdex="l">MR.</NAME> 
<NAME mdcx-*2">testfirst</NAME> 
<NAME index="3">lestlast</NAME> 
15 <EMPIX>YEEID>httpy/bncmazie/"uiteroonnect/Saba/com.sabainter 
connectObjectID@170179/6805</EMPLOYEEIE>> 

<EMPLOYEETYPE >Pennancnt</EMPIjOYEETYPE> 
<SYNCIND/> 
<DUNSNUMBER/> 
<ADDRESS> 
<ADDRLINE index="17> 
<ADDRLINE index- "27> 
<CITY/> 
<COUNTRY/> 
<POSTALCODE/> 
<STATEPROVN/> 
<fTEUEPHONEl/> 
<TELEPHONE2/> 
<FAXl/> 
<PAPENTID/> 
<EMAIL/> 
</ADDRESS 
<NAME2/> 
<CURRENCY/> 
<DESCRIPTN/> 
</EMPLOYEE> 
<USERAREA> 
<MNAME/> 
<TERR rPORYTD/> 
<COMPANYlD/> 

<STARTEDON>2000-07-24 00:00:00.0</STARTEDON> 
<TERM I N ATEDON/> 

<LOCATIONTD>http ^/bnemazie/iiilerconnect/Saba/coin.saba.inter 
conncct.ObjcctID@cd92/6801 </LOCATIONID> 
<RATE/> 

<SSNO>lll-ll-2222</SSNO> 
<GENDER>0</GENDER> 
<SHORTDESCRIPTN/> 
<JOBTYPEID/> 
<MANAGERID/> 
<QUOTA/> 

<UPDATEDON>provide<AJPDATEDON> 
<UPDATEDBY>provide</UPDATEDBY> 
<MAXDISCOUNT/> 
<HOMEDOMAIN/> 

<USERNAME>1093-202<AJSERNAME> 
<FLAGS>0</FLAGS> 
<PASSWORD/> 

<STATUS>Full Time</STATUS> 
<LOCALEID/> 

<EMPLOYEENO>185</EMPLOYEENO> 
<SPLIT/> 

<CREATEDON>providc</CREATEDON> 
<OBJTYPE/> 

<OBJSTATUS>new^OBJSTATUS> 
<DESIREDJOBTYPEID/ > 
</USERAREA> 
</SYNC_EMPLOYEE> 
</DATAAREA> 
</SYNC_EMPLOYEE_001> 
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The Monitor then receives the BOD from the Accessor 
and instructs the external system Requestor to deliver the 
personnel change to the SABA system. The Requestor then 
delivers the Sync Personnel document over the network to 
the SABA system. The SABA Updater receives the Sync 
Personnel document. It uses an XSL stylesheet to transform 
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the document into the canonical format used internally. The 
following is an example XSL personnel stylesheet: 
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<xsl:sty1esheet 
xmlQs:xsI«"http:/Avww.w3.org/1999/XSUTraasform"> 

<!~COPYRIGHT NOTICE Copyright (c) 1997-2000 Saba 
Software Inc., 2400 Bridge 

Parkway, Redwood Shores, California 94065-1166 USA. All 
rights reserved. -> 

<xsl:output indent- "yes" method- "xm I "omit-x ml - 
declaratio n= ' no 7> 

<xsl:template match-"* [/"> 

<xsl: apply- templates^ 
</xsl:template> 

<xsl:template match="text () | @*"> 

<xsl:vahie~of select-'. "/> 
</xsl template> 

<xsl:template match-"SYNC_EMPLOYEE_JX)l"> 
<xsl; for- each select=7"> 

<SabaObjectSerialization xmlns:dt»"urn:w3- 
org:xmldatatypes*> 

<SabaObject> 
<xsl attribute 

name="type">ccnn.saba.buscbj\SabaEiriployee</xsl^ttribute> 
<ral:attribute name— "status "> 

<xsl:value-of 
selcct-7/USERAREA/OBJSTATUS 7> 

<xsJ:if test='//USERAREA/OBJSTATUS=' ' "/> 
</xsl:attribute> 
<xsl attribute name="id"> 

<xsl:value-of select-"//EMPLOYEEID7> 

<xsl:if test= '//EMPLOYEE ID^' * 7> 
</xsl:attribute> 

<titlc dt:typc="string" dt:size="10"> 

<xfil:va!ue-of select-"//NAME[l] 7> 
<JtMc> 

<fname dt:type="string' dt:size="25"> 
<xsl:valuc-of select="//NAME [2] 7> 
<rsl:if test=7/NAME[2p * 7> 

</fnamc> 

<lname dttype» "string" dt:size="25"> 
<X3l:valuc-of sclect-7/NANE[3] '/> 
<xsl:if test=7/NAME[3>' ' 7> 

<Aname> 

<mname dt:type="string" dt3ize="25*> 

<xsl:value-of select- 7/USERAREA/MNAME7> 
</mname> 

<homephone dtitype-'string" dt:size-"25"> 
<xsl:valuc-of select»7/TELEPHONEl 7> 
<tfhomephone> 

cworkphone dt:type= "string" dt:size"25"> 

<xsl rvalue- of selecU»7/TELEPHONE27> 
</workphone> 

<fax dt:type=" string" dt:size"25"> 
<xsl:valuc-of select-7/FAX17> 
</fax> 

<crcatcd_on dtrtypc- "string" updateFlag-"No"> 
<xs I attribute 
name-"provide" >tme</xs\ :attribute> 
</created_on> 

<created__by dtrtype- "string" updateFlag-"No"> 
<xsl attribute 
name-"provide ">true</xs]:attribute> 
</crcatcd by> 

<updated_by dLtype-"string"> 

ccslrattributc 
name="provide" >true</xsl :attribure> 
^updated by> 

<updated_on dt:type=»"dateTime"> 
oral :attribute 
name="provide" >true <fxs\ :attribute> 
<tfupdated_on> 
<territory_id> 

<xsl attribute namc-"tdref'> 
<xsl:value-of 
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select=7/USERAREA/rERRTT0RYID7> 
</xsl:attribute> 
^ </territory_id> 

<custom0 dt:type"string"> 
<xslrvalue-of 
select-"//USERAREAyCUSTOM0"/> 
</custotnO> 

<customl dt:type="string"> 
10 <xsl:vahie-of 
selcct="//USERAREA/CUSTOMl "/> 
</customl> 

<custom2 d t: type-" string "> 
-oralrvaruc-of 
selects 7/USERAREA/CUSTOM27> 
15 </custom2> 

<custom3 dt:type="string"> 
<xsi:varue-of 
select~7/USERAREA/CUSTOM37> 
<^custom3> 

<custom4 dt:type»"string"> 
<xsl:vahie-of 
sclecU"//USERAREA/CUSTOM4"/> 
</custom4> 
<company_id> 
oral attribute name-"idref"> 
<xslrvalue-of 
select="//USERAREA/COMPANYID"/> 
25 <Ksl:if 

test=.7/USERAREA/COMPANYID-' ' ">btsut000000000000001<tol:if> 
</xsl:attribute> 
</company_id> 

<addrl dt:type-"string" dt;size-"80"> 

<xsl:value-of select»7/ADDRLENE[l]"/^ 
</addrl> 

<addr2 dt:typc=" string" dt:size»"80"> 

<xsl:value-of select-"//ADDRLINE(2] 7> 
<&ddr2> 

<city dt:type= "string" dt:size="50"> 

<x5J:vahie-of selcct»7/CITY"/> 
<^city> 

<state dtitypc-' string" dtrsize— "50"> 
<xslrvalue-of > 
select-"//ADDRESS/STATEPROVN7> 
</state> 

<zip dt:type-" string" dt:size-"80"> 

<xslrvalue-of select=7/POSTALC0DE7> 
<}zip> 

<country dt:type="string" dt:size="80"> 
<xsl:value-of setect-7/COUNTRY"/> 
</ccnmtry> 

45 <email dt:type-"string"> 

<xslrvaruc-of sclect»"//EMAIL7> 
</email> 

<cmpIoyee_no dt:type="5tring"updateFlag>-"No" 

dt size="80"> 

<xsl:varue-of select-7/EMPLOYEEN07> 
50 <xsl:if test=>7/EMPLOYEENO=i' 1 "/> 

</cmploycc no> 

<status dt :type="number ,, > 
<xsl:vnlue-of select-7/USERAREA/STATUS7> 
<xsl:if test-7/USERARrWSTATUS-' 1 ">Full 

Hme</xsl:if> 
55 </status> 

<password dt:type-"string" updateFlag-"No"> 
<xsl:valuc-of 
select~7/USERAREA/PASSWORD7> 
otshif 

tesU-7/USERAREA/PASSWORD-' 1 ">412ABF98CDF3EF99<^tsl:if> 
60 </password> 

■cusername dt:type="string" update Flag="No"> 
<xsl:varuc-of 
select- 7/USERAREA/USERNAME7> 
</useraamc> 
<manager_id> 
6S <xsl attribute name-"idref'> 

<xsl:value-of 
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-continued 



select«7/USERAREA/MANAGERID7> 
<tfxsl:attribute> 

</manager_id> 

<cmp_typc> 

<xsl:value-of select- 7/EMPLOYEETYPE7> 
<xsl:if test-7/EMPLOYEETYPE- 1 ' 7> 

</cmp_type> 

<started_on dttype="dateTime"> 
<xsl:value-of 
sclect^7/USERAREA/STARTEDON7> 
</sLarted_on> 

<terminated_on dt:type-"dateTime"> 
<xsl:vahic-of 
selects 7/US ERAREA/TERMINArEDON7> 
</terminated_on> 
clocation_id> 
<xsl:auribute name»"idref"> 
<xfiJn/alue-of 

sctcc^7AJSERAREA/LOCATIONID7> " " 

<!- Change value for default 

locatioD id --> 

<xsl:if 

test=7/USERAREA/LOCATIONID=' ' ->locat000000000001000<tel:if> 
</xsl:attribute> 
</locatioo_id> 

<max_dis count dttype="number"> 
<xsl:value-of 
select- 7AJSERAREA/MAXDISCOUNT7> 
<xsl:if 

test=7/USERAREA/MAXDISCOUNT=' ' ">0<Vxsl:if> 
</max_discaunt> 
<split dt.*type° "string "> 

<xsl:vaIue-of select=7/USERAREA/SPLIT7> 

<xsl:if 

tcst-7/USERAREA/SPLrr-' ' ">domin000000000000001</xsl:if> 
<split> 

<rate dt:type-"number"> 
ocslrralue-of select=7/USERAREA/RATE7> 
<xsl:if 

test-7/USERAREA/RATE-' ' ->0</xsl:if> 
<#atc> 

<quota dt:type=." number" > 

<xsl:value-of select- 7/USERAREA/QUOTA7> 
<xsl:if 

te£t=7/USERAREA/QUOTA=' ' ">0«*sl:if> 
</quota> 
<jobtypc_id> 

<xsl:attribule name="idref"> 
<xsl:vaIue-of 
select^ 7/USERAREA/JOBTYPEID7> 
</isl:attribute> 
<^jobtypc_id> 
<ss_ao dt:type= "string" > 
<xs]:value-of select=7/USERAREA7SSN07> 
<xsl:if test»7/USERAREA/SSNO»' * 7> 
</ss_no> 

<gender dt:type=" number" > 

<xsl:value-of select- 7/USERAREA;GENDER7> 
<icsl:if test-7/USERAREA/GENDER-' ' 7> 
</gender> 
<home_domain> 
<ol attribute name-"idref > 
<xsl:value-of 
select- 7AJSERAREA/HOMEDOMAlN7> 
<xsl:if 

test-7/USERAREA/HOMEDOMAIN-' * 7>dominOOOOOOOOOOO 
0001</x5ldf> 

</xfil:attribute> 
</ho me_domain> 
<des ired_job_type_id> 
<acsl:attribute namc="idref"> 
<xsl:vaIue-of 
selects 7AJSERAREA/DESIREDJOBTYPEID7> 
</xsl:attribute> 
</desircd^job_Jypc _id> 
<docale_id> 

otshattribute name-"idref"> 
<xsl:value-of 



select»7/USERAREA/LOCALEID7> 
<ol:if 

5 test- 7/US ERAREA/LOCALEID-' ' ■>local000000000000001</jtsl:if> 

^xsl:attribute> 
<^locale_id> 
<flags dt:type-"string"> 

<3tsl^ahie-of selcct=7/USERAREA/FIAGS7> 

OEShif 

10 test- 7/US ERAREA/FLAGS-' ' ">0000000000<yxsl:i£> 
</flags> 
<time2Qiie_id> 
<xsl:attribute name-'idref"> 
<xsl:value-of select»7/TIMEZONE7> 
<!— Change value for default 

15 timezone_id — > 

<nl:if 

test-7/nMEZONE-' "">t2one00000O000000008<^xsl:if> 
</xsl attribute* 
<#imezone_id> " " 
</SabaObject> 
<ySabaObjectSerialization> 
<tfxsl:for-cach> 
</xsl:template> 
</xslstylesheet> 
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The following is the equivalent Local Format document, 
a generated Saba Person in Saba Canonical Format: 
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<SabaObjectSerialization xmlm:dt-"ura:w3-org3mldatatypes"> 
30 <SabaObject type-"com^aba.busobj.SabaEmployee" 
status="existiiig" 

id="http^/bnemazie/intercx>nnect/Saba/coni. saba. interconnect. Object 
ID@170179/6805"> 

-ctitlc dttype -"string" dt:size*» ,, 10">MR.<Vtitle> 
<fname dttype="string" dtsize="25">testfirst</fname> 
35 <lname dt:type-"string" dtsize—"25">testlast</lname> 
<mnamc dt:type-"string" dtsizc="257> 
<homephone dt:type- "string" dtsize="25">972 580 
7645<7homephone> 

cworkphonc dt:typc="string' dt:sizc« , 257> 
<fax dt:type= "string" dt:size="257> 
<updated_by dt:type-"string' provide-"tru©7> 
<updated_on dt:typc="dateTimc" pro vide- "true 7> 
<territory_id idref-" '/> 
<custom0 dt:type-"string7> 
<customl dt:type»"5tring7> 
<custom2 dt:type="string"/> 
<custom3 dt:type-'string7> 
<custom4 dt:type-'string"/> 
<company_id idref»"bisut000000000000001"/> 
<addrl dt:type="string" dt:size-"80">1213 addrl 1234<yaddil> 
<addr2 dt:typc="string" dt:size-"807> 
<city dt:type="string" dt3ize="50">trving</city> 
<state dt:type=" string" dt:size="50">TX^/state> 
50 <zip dt:type-"string" dt:size-"80">75038-</zip> 

<country dt:type- "string" dt:size="80*>US</couiitry> 
<email dt:type**"string7> 

<employee_jio dtUype-'atring" dt:size-"80">185</employee__no> 
<status dt:type="number">FuIl Hme<fetatus> 
cpassword dt:type="string">412ABF98CDF3EP99</password> 
55 <username dtAype-'string">1093-202</useraame> 
<manager_id idref=»" '/> 
<emp_type >Permanent </emp_type> 
<started_on dt:type-"dateTime'>2000-07-24 
00:00:00.0</startcd_on> 

<terminated_on dt:type="dateTime"/> 
<location_id 

idre f =• " http y/bnemazic/inte iconncct/Saba/co m.saba. interconncct.Obj 
ectID@cd92/68037> 

<max_discount dt:type-" number" >0</max_discount> 
<split dt:type="string">domui000000000000001< , split> 
<rate dt:type="number">0</iate> 
<quota dt:type-' , number">0-</quota> 
65 cjobtype_id name»"idreP/> 

<ss_no dt:type= "string" >1 11 -ll-2222</ss_no> 
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delivered depending upon how the recipient registers. The 

-continued recipient may Poll for messages using 

IPostman.getMessagc( ) or handle incoming messages by 

<pndcrdt^;number'>o</gendcr> implementing IRecipient.recieveMessage( ). The 

<home_domaio idref="domin0000000000000017> in * */ \ « • « i tti • • 

<d C sir C d_job_t yP e_id idref-' •/> 5 IPostman.connect( ) method has an optional IRecipient 

<iocalc_ididref="localoooooooooooooor/> parameter. If a valid IRecipient is passed, incoming mes- 

<flags dt:type="string">o</flag?> sages will be delivered using that interface. In this case, 

<timezone_jd idref-" tzone000000000000008"/> behind the scenes, an InboxAssistant is created in a separate 

<ysabaObjcct> mread to walch lhe Inbox 0D behalf of ^ rec i p i enL when 

<ysabaObjedSenaii Za tioa> ^ a message is sent using IPostman.sciidMcssagc( ) the Deliv- 

eryService is responsible for making sure that the message 

A SabaEmployee object is instantiated based on the gets delivered to the appropriate Inbox. If it cannot it must 

canonical XML document. This object is then saved, com- report or log an error. 

mitting any changes to the database. In the simple case where a message recipient is in the 

The set of interconnect components is extensible so same installation as the sender, the DeliveryService will put 

additional functionality can be added over time. Adding a 15 the message in the recipient's Inbox and be done with it. The 

Searcher component allows a site to be "exchange message will stay there until the recipient or the InboxAs- 

enabled"— able to share catalog (or omer) information with fetant takes it out When fashed using the service, an 

other sites. .In this way users can get results ifrom searches interconnect client may disconnect from or release the 

that combine remote catalog offerings with local catalog Inbox Discoimecting tells tbe DeliveryService to maintain 

offerings. Addmg a Purchaser component makes a site 20 m s ^ the rec ^ ent mtends recQnncct ^ later 

eCommerce enabled — able to offer products for sale via g , . - ^ „ ~ „ . 

an automated interface. Tnis enables learners who choose ^ ^T^k DehveryScrvioc resourccs associ ' 

classes from a catalog that has been shared on SabaNet to ated witn the Inbox. . . 

. „ • o u xt ♦ a 17 * * ij When the DeliveryService determines that message is 

purchase them via SabaNet. A Versioner component could ■ ■ i * , & t 

tr *u u*i * * * *• ii i . ,i ^ . . . „ destined for a recipient in another Interconnect location, the 

offer the ability to automatically upgrade to the latest version 25 . . ~ « • .a j *t_ mv 

p r, . . J J°\ t , . . local DehveryService must forward the message to its peer 

of the software or to automatically purchase a license ~ „ t . . *V 

extension via a Licensor component. DehveryService at that location. The service identifier m the 

As described above the DeliveryService is a key compo- messa g e t s ^^ss is used to determine whether the 

nent of the InterconnectBackbone. Interconnect messages * C1 P ient 15 ^ or ^ mo f ^^ff ^ 

follow an persistent asynchronous protocol. Messages are 30 5°* (aS , ^ tUm ? d T by I°etAddress : getIxcalHost( 

sent and received with a message payload. Message pay- ))-getHostName( )) and Interconnect service name. For 

loads are opaque to the DeliveryService, any object may be f xam ( ?^ a nam f d / SabaAccessor; running on Saba 

r n * • * ... i host flamenco would have an URI of the form rmi:// 

sent as a message payload. A message recipient may reply to flamenco saba con^abaWeb/Saba/Accessor" 

a message by constructing a reply message from the original H^nco.saba.com^ataWeb/Saba/Accessor' . 

message and sending that reply • is a separate asynchronous 35 A The SemceManager will look at the seryiceURJ and 

me aee determine whether the service m remote or local, if it is 

«. a — a * - * , r remote it will resolve the address with it's remote peer. 

Message senders and recipients are responsible for syn- „ t 4l _ , . « . » ..... * 

u *u ■ T. r m i 1, Key to the design of the Interconnect is the notion of 

chromzmg their own messages. There are message ID fields . J , t , r * i ^ , ... 

in the Message that may be used for this purpose. AMessage ^ bl % P rotocols - T ° ^nwdate this, the 

contains (1) The sender's InterconnectAddress (2) The 40 Dehvery Service has ^2 components(l) , Delivery Service (2) 

reci P ient'sIntercormectAddress(3)Thesender'scredential S Petsastcnt Messa g e Manager. The Delivery Service wntes 

(4) AmessagelD (5) AreplylD (6) The message payload (an m ^ ag< ? t0 outbound ^ eucs (* th <; ™* to »» 

Object). Message sendee and recipients have an Intercon- ^ hvered to ]I an ^6 Persistent Message 

nectAddress. This Address is managed by the DeliverySer- ™T*V.? . t0 ^ hver ^ m ™*& to 

vi«andcontams(l)AnInboxideniineranboxID)ass4ned « * ehosMh ^ «^ge ^ ^f^d for. The persistent Message 

by the local DehveryService (2) A String in URI fonnat Ma ° ager has the 0565 P^ggable transport protocol. For 

identifying the service (mServiceURI), (3) An Object iden- ^™nting a protocol us.ng RMI aclass needs to be 

tifying the associated User (mUser). Unplem ^ ^ PMTrans P ort l The P ^ slstent Mes " 

The InboxID is used by a DeliveryService for local sage Mana 8f r < PMM > act ^ 35 me H stener l i° r f 0 "* 

™, y rT11 , -o _ messages. Messages received are put into inbound queues, 

message routing. The URI identifies the specific software 50 it _ T% & 1 . „ 6 . , r r . . t I 

component and is used to determine whether the Intercon- ^ De ^7 ^ I 7 lce . K dehvers mcssa Ses from the inbound 

nectAddress is local or remote. To send a message, an qu ^. cs to # . mc f"*^"/. . . tl - u 

» . . „u^ t /i\ M * x f \, The rationale behind this separation is to allow for the 

Interconnect client must: (1) construct a Message for the , A , n • . „ .11 j 

• M « j m . j„ • • , A\ jja 1 j * Interconnect Delivery Service/P MM to be deployed across a 

given sender and recipient, (2) add the message payload to ., • ^ * . . 1 « • 

the message, (3) set the message ID or the reply ID if ss wule vanety of communication protocols. Support^ a new 

needed, (4) send the message using the DehveryService's P ro . toco1 , K ^ , a traaS P°" ^P 8 

IPostman interface. If the message is local it will be deliv- ploU *° l : T** pl ° loco1 ™P lem f nted . 35 

ered using the InboxID. If it is remote it will be forwarded ^ 3116 l , m,late and acce P' n connecU I3 0DS ' 5611(1 f d r6ce i v , e 

to the appropriate remote DeliveryService for delivery at mesSa ^ tetmmate gracefully, etc. For exampk the fol- 

that location 60 ^ 0Wm S ste P s would be performed to build a TCP/IP socket 

In order to use the DehveryService, a connect must first Interconnect Transport: 

be made. Upon connection the DehveryService assigns an L Implement a interconnect listener/accepter 

InboxID that is used internally for message routing and 2 - Implement a client connection initiator 

synchronization. This InboxID is used in subsequent calls to 3. marshal and write interconnect messages onto a socket 

the DeliveryService. 65 4. read and unmarshal interconnect messages from a 

Once connected, messages may be sent or received from socket 

the DeliveryService. There are two ways messages can be 5. implement the IPMTransport interface 
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A discussion of mapping Ids from one system to another 
using the POID concept follows. When the Accessor 
receives a request to export an object to a stream, it is passed 
a user object and a platform ID (POID). In this case the 
POID is an ID associated with the local object in this system. 5 
Generally this ID will be acquired from another exported 
document or as a result of a Monitor event however, some 
initial mappings may need to be provided to bootstrap the 
system. 

Given the POID, the Accessor looks up the local ID and 1Q 
the document type in the Mapper. It is an error if there is no 
associated local object. The Accessor then uses the docu- 
ment type to look up the appropriate stylesheet, transformer 
and XMLHelper to use during the accessing and transfor- 
mation steps. 

Using the AccessorReader for the configured system, the 15 
local object is extracted into a stream in a system specific 
XML format. The XML stream, the stylesheet and an output 
stream are then passed to the transformer that writes the 
transformed XML to the new stream. The transformed 
stream is then returned. 20 

This is in the simple case where the XML to export 
contains no external references to objects in the source 
system which are not contained in the generated XML. In 
the more complicated case, the XML stream is not fully self 
contained, Le. it contains references to objects that are not 25 
part of the XML stream. XML however may contain the 
local Object Id of this Object, this Id is meaning less outside 
this system. This Id needs to be replaced with its POID. 

The Accessor service needs to attempt to insure that all 
unresolved references in the outbound XML document are 
represented in the form of a POID. During export, the 
Accessor must find or create a POID for each reference 
encountered and fix up those object references in the XML 
stream. The Accessor will use the Mapper to determine if the 
referenced object has an associated POID. If a POID does 
not exist, one will be created and added to the Mapper's 35 
tables. 

Step by step on the Accessor side: 

1. The Accessor requests a document be exported by 
invoking the Accessor method: 

Reader IAccessor.getObjectReader(UserObject user, 40 
POID poid) 

2. The Accessor looks up the local object ID from the 
Mapper 

LocalObjectID Mapper.getLocalID(POID platformID) 
If there is no local ID an exception is raised. 

3. The Accessor looks up the document type from the 
Mapper: 

String Mapper. getDocumentiype (POID platformID) 
If there is no document type, a default is used for the 
configured AccessorReader. 

4. The Accessor looks up the stylesheet, IXMLHelper and 
ITransformer using the docType. 

5. The Accessor requests the object in XML format from 
the AccessorReader: 

Reader IAccessorReader.extractObjectReader( 
LocalObjectID locallD, IXMLHelper helper) 

6. The Accessor fixes up ID references in the XML 
stream. It scans the stream looking for foreign POIDs. 

7. When a reference ID is encountered by the Accessor, it 60 
resolves it to the POID using the Mapper. If no POID 
exists one is created. The POID is written to the XML 
stream. 

8. An output stream is created and the document is 
transformed: 65 
void ITransformer. transform(String stylesheet, Reader 

in, Writer out) 
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When the Importer receives a request to import an object 
from a stream, it is passed the stream, a user object, the 
document type and a platform ID (POID). This POID is a 
foreign ID, created when the document is exported from the 
source system. 

The XML stream, a stylesheet and an output stream are 
passed to the transformer and a new XML stream is pro- 
duced. This new stream is passed to a platform specific 
object that inserts it into the system. On insert, a local object 
ID is created by the system and returned 

When the local ID is returned to the Importer, the 
Importer asks the Mapper to map the foreign POID to the 
Local Object The POID is then returned to the requestor in 
the import status reply. 

This is in the simple case where the XML to import 
contains no external references to objects in the source 
system which are not resolved in the XML. 

In the more complicated case, the XML document not 
fully self contained. Hie document to import contains ref- 
erences to objects that are not part of the XML document. 
The import service attempts to resolve these references to 
insure the referential integrity of the object being imported. 
During the transformation phase, the Importer must resolve 
the foreign references to local objects and fix up those object 
references in the XML stream. 

The specified object may have already been imported in 
which case there will be an entry in the local Mapper's 
foreign POID map. The Importer asks the mapper to resolve 
the POID to a local object. If this object has been mapped, 
a string representation of the Object ID is used to replace the 
foreign POID in the XML document. 

In the case where the object has not been previously 
imported the importer has two choices. Either it can fail and 
report an error, or it can attempt to pull the object from the 
foreign system. It is reasonable to make this a configurable 
option and perhaps only support error reporting in the initial 
release. 

Step by step Id mapping on Import: 

1. The Subscriber requests a document be imported by 
invoking the Ilmporter method: 

ImportStatus IImporter.importObjectFromStream( 
POID poid, UserObject user, Reader stream, String 
dociype) 

2. The Importer looks up the stylesheet, IXMLHelper and 
ITransformer using the doctype. 

3. An output stream is created and the document is 
transformed: 

void ITransformer.transform(String stylesheet, Reader 
in, Writer out) 

4. The Importer fixes up foreign ID references in the XML 
stream. It scans the stream looking for fbreign POIDs. 

5. When a foreign ID is encountered by the Importer, it 
resolves it to the local ED using its Mapper. The local 
ID is written to the XML stream. 
LocalObjectID Mapper.resolveForeignObject(POID 

foreignID) 

6. The fixed-up XML stream is passed to the Importer- 
Writer to insert into the system. 
LocalObjectID insertObjectFromStream(Reader in, 

IXMLHelper helper) 

7. Map the new local ID to the original foreign POID 
passed with the import request. 

void Mapper. mapForeignObject(POID foreignID, 
LocalObjectID locallD) 
So far the discussion has been around the Interconnect/ 
Connector framework. The following discusses Connector 
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Specific plug ins, and defines the specific components for 
each connector. Taking Saba Connector as an example: 

a. SabaChangeManager — This class extends the Change 
Manager, starts a thread that polls the database for 
changes. Once a change is detected the change is 
passed over to the Monitor for further processing. This 
class has the specific logic to poll Saba database. 

b. SabalmporterWriter — This class extends the Importer- 
Writer and has the logic to import Objects in Local 
format (SCF )into Saba system. 

c. SabaAccessorReader — This class extends the Acces- 
sorReader and has the specific logic to retrieve objects 
from Saba system in local format. 

Every new connector has to implement these 3 classes to 
work with application connecting. Extending this we have 
sapChangeManager, saphnporterWriter and sapAccessor- 
Reader. 

" Information' Server 

The present invention relates to a novel information 
distributor method and apparatus. The present invention can 
provide services for consolidating, analyzing, and delivering 
information that is personalized, relevant, and needed. 

It employs metadata-based profiles to match information 
with users. User profiles may include skill competencies and 
gaps, roles and responsibilities, interests and career goals. 

The Platform services provides the interface and infra- 
structure for building agents that work in concert to decide 
what information is delivered, when it is delivered, and how 
it is delivered. 

The platform services integrate with the Platform Inter- 
connect Server to work across different networks and dis- 
parate information systems. This allows users to receive 
information from a variety of sources and locations via a 
single, consistent interface. 

The present invention uses an Information Distributor 
Developer's Kit (IDK) to be used by software application 
developers of ordinary skill in the art. 

The platform of the present invention identifies and fills 
information gaps across the corporate value chain. IDK 
provides the infrastructure and core functionality to find and 
deliver relevant and targeted information. In an 
embodiment, the IDK enables more sophisticated querying 
and matching functionality than in the prior art and serves as 
the technology underpinnings for a stand-alone Enterprise 
Information Portal (EIP) solution. 

For more information on RDF, refer to the W3C home 
page, incorporated by reference in its entirety, at the URL 
www.w3.org/RDF/ and formal specification located at URL 
www.w3.org/TR/REC-rdf-syntax/. 

The above sources of information are incorporated by 
reference in their entireties. 

FIG. 11 shows a structural overview of an IDK UOO of the 
present invention. IDK UOO is associated with a language 
1102, such as RDF, for representing web metadata, a lan- 
guage for querying web metadata, and a set of APIs 1104 for 
defining information services based on what data is used, 
when and how a match is performed, and what is done with 
the results. 

FIG. 12 shows a functional overview of an Information 
Distributor 1201 of the present invention. IDK 1100 can 
annotate and match broad resources 1200, support diverse 
sources, conditions, and delivery options 1202, provide an 
easy migration path 1204, and leverage open standards 
1206. 

In an embodiment of the invention, Information Distribu- 
tor 1201 provides a flexible mechanism for annotating and 
matching web resources 1200. Information Distributor 1201 
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can locate and deliver a wide variety of resources, from web 
pages to Business Objects. Information Distributor 1201 
also supports a wide variety of descriptive information 
required by business applications, from standard web meta- 
5 data to catalog information to skills and competencies. 
Information Distributor 1201 also supports a broad vari- 
ety of information sources, match conditions, and delivery 
mechanisms 1202. Information Distributor 1201 generates 
matches under a variety of circumstances and supports a 

J0 variety of options for delivering match results. 

Information Distributor 1201 provides an easy migration 
path 1204. A software developer of ordinary skill in the art 
can write queries using a combination of Java code and 
SQL. IDK provides equivalent functionality using a higher- 
level languages for representing and querying data and 

15 simpler programming APIs. Information Distributor 1201 
also leverages open standards 1206 by supporting industry 
standards such as RDF and XML. Support for industry 
standards helps ensure the availability of third-party tools 
that interoperate with IDK and increases the set of data and 

20 information on which IDK can act. 

In an embodiment of the invention, Information Distribu- 
tor 1201 can determine if a new software developer has just 
joined a new project. If one of the skills required for the new 
software developer's new assignment is knowledge of 

25 XML, then upon joining the project, Information Distributor 
1201 automatically send an email to the new software 
developer containing information about the company's stan- 
dard "Introduction to XML" course. 

In an embodiment of the invention, Information Distribu- 

30 tor 1201 can keep a development manager informed about 
the status of the other development groups in his division. As 
part of his custom home page provided by the corporate 
portal, he can view a list of the most recent updates 
submitted by each development manager, and call up each 

35 report in his web browser. 

In an embodiment of the invention, Information Distribu- 
tor 1201 can detect when an affiliated training provider has 
made available a new advanced class in Java. Information 
Distributor 1201 sends email to all advanced and expert Java 

40 programmers in the company announcing the availability of 
this class. 

In an embodiment of the invention, Information Distribu- 
tor 1201 can detect when the HR department institutes a new 
approval practice for all new hires. Information Distributor 

45 1201 assures all luring managers in the company receive a 
new entry in the Corporate Information channel that 
explains the policy change. 

If an updated price list for a region is generated, Infor- 
mation Distributor 1201 sends an email containing the new 

50 price information to all dealers in that region. 

If an employee has a change in his family status, such as 
if the employee has a baby, the next time the employee views 
the HR department's benefits page in his web browser, the 
Information Distributor assures customized plan and deduct - 

55 ible information appears that is appropriate for his new 
family status. 

Referring again to FIG. 11, in an embodiment, the Infor- 
mation Distributor adopts a new standard for web metadata 
and its definition of a high-level language 1102 for querying 

60 this metadata. 

Metadata is structured information about information, and 
is used to identify, categorize, and locate resources of 
interest. Resource Description Format (RDF) is a new, 
XML-based standard for associating arbitrary metadata with 

65 any web resource. It can be used to describe resources 
ranging from a course catalog on the WWW to a business 
object representing a client. 
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la an embodiment a language used to query web metadata 
1102 may be RDF Query Language (RQL), an XML-based 
query language for writing queries against RDF data. It can 
represent both simple and complex queries, and can also 
accommodate metadata matching, where a metadata 
description can be part of the query. For example, this allows 
a particular employee's complete skills gap — expressed as 
an RDF description — to be used in a query to locate classes 
that fill the gap. 

FIG. 13 shows an exemplary view of APIs 1104 associ- 
ated with the Information Distributor. In an embodiment, the 
Information Distributor partitions information matching and 
delivery issues into three areas, each addressed by a distinct 
type of agent, Import Agents 1300, Match Agents 1302, and 
Delivery Agents 1304. The combination of Import Agent 
1300, Match Agents 1302, and Delivery Agents 1304 is a 
novel combination of the present invention. 
' Import Agents 1300 create and' import the RDF descrip 1- 
lions used by IDK. Import Agents 1300 can generate meta- 
data from a variety of sources, from existing web pages and 
business objects to content management systems to enter- 
prise applications. 

Match Agents 1302 determine what matches and queries 
occur under what conditions. Match Agents 1302 can be 
triggered by a request to a web or application server, by 
specific events, or on a regularly scheduled basis, A Match 
Agent 1302 also specifies the RQL and any input metadata 
to use as the metadata query. 

Delivery Agents 1304 dispatch the results of a query or 
match. In an embodiment, Delivery Agents 1304 integrate 
with a variety of delivery mechanisms, from web page 
generation and XML datagrams to email and event messag- 
ing systems. 

In an embodiment of the invention, FIG. 14 shows an 
exemplary view of using Information Distributor or IDK 
1100. A software developer of ordinary skill in the art can 
use IDK to query objects 1400 or to implement custom 
delivery service 1402. In an embodiment, Query Objects 
1400 may be used similarly to today's finder methods, that 
is, a high-level mechanism to query SABA business objects, 
but using and requiring knowledge of RDF and RQL. 

FIG. 15 shows an exemplary overview of Query Objects 
1400. The invention, through a user associated with the 
invention, such as but not limited to a software developer of 
ordinary skill in the art, demies RDF Metadata Mappings 
1500 for the objects and metadata of interest. Then, the 
invention Authors An Import Agent 1502 to capture this 
metadata. The invention may then Author An RQL Docu- 
ment 1504 to query this metadata and author a Match Agent 
to Perform the Query 1506 and a Delivery Agent to act on 
the query results. 

FIG. 16 shows an exemplary overview of Implement 
Custom Delivery Service 1402. The invention, through a 
user, such as but not limited to a software developer of 
ordinary skill in the art, may use the invention's IDK to 
novelly Implement a Custom Information Delivery Service 
1402, using RDF, RQL, and the full IDK interface. In an 
embodiment, the invention Defines RDF Metadata Map- 
pings 1600 for the objects and metadata of interest. The 
invention Authors An Import Agent 1601 to capture this 
metadata. The system and method of the present invention 
then Authors An RQL Document 1602 to query this meta- 
data. The invention then Authors a Match Agent 1604 to 
perform the query, and Authors a Delivery Agent 1606 to 
dispatch the query results. The invention then Integrates All 
Agents 1608, including the import agent, the match agent, 
and the delivery agent, into the existing system. 
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In an embodiment of the invention, Information Distribu- 
tor (IDK) is a Software Development Kit delivered as part 
of Platform 4.0. It provides the infrastructure and basic 
functionality needed to build and customize the Enterprise 

5 Information Portal. 

IDK provides the infrastructure and services to perform 
metadata-based queries. Unlike traditional text-based search 
engines, in an embodiment the IDK operates solely on 
descriptive data about resources, rather than the resources 

10 themselves. 

In an exemplary embodiment of the invention, referring 
again to FIG. 13, IDK defines interfaces for metadata 
generation (Importers or Import Agents 1300) and matching 
(Resolvers or Match Agents 1302) and for delivering query 

15 results (Dispatchers or Delivery Agents 1304). Combina- 
tions of these three services allow the Information Distribu- 
tor to interoperate with a variety of enterprise systems and 
to service queries in a broad range of application domains'. 
In an embodiment, a portal server may be delivered using 

20 IDK. 

Import Agents are responsible for consolidating a variety 
of information sources. Importers integrate with various 
external systems, analyze the descriptive data about specific 
resources in the system, and import this data into a custom 
25 RDF database. Exemplary information sources include 
internal email systems and Intranets, SABA EMS, ERP 
systems, and the World Wide Web. 

Common tasks supported by Import Agents include: 

Executing batch imports 
30 Scheduling imports at regular intervals 

Analyzing and translating metadata formats 

Specifying a target database 

Integrating with SABA Interconnect 
3S Match Agents are responsible for matching between infor- 
mation resources and user profiles. Match Agents execute at 
regular intervals or in response to specific requests. They 
perform intelligent comparisons between metadata descrip- 
tions of imported resources and user profiles. These com- 
40 parisons return a set of information resources as the match 
result. 

Because they act on detailed user profiles, Match Agents 
can finction as personal agents, identifying those resources 
most relevant to a user's job, interests, or objectives. For 

4S example, they can determine that a user requires knowledge 
of a specific technology for a new job assignment, and 
deliver suggestions for classes covering that technology. 

Because they match against categorized metadata, 
Resolvers can return more accurate and meaningful results 

50 than is possible with traditional text-based searches. For 
example, Match Agents can return only documents that have 
been updated within the last week. Or they can distinguish 
between articles about an individual and articles written by 
the individual. 

55 Delivery Agents are responsible for delivering the results 
of a match to the correct recipients in the appropriate 
fashion. Delivery Agents integrate with various delivery 
mechanisms, delivering either pointers to the match results 
or the actual information itself. Typical delivery vehicles 
60 include e-mail, web servers, and enterprise portals. 

Common tasks supported by Delivery Agents include: 
Delivering results immediately upon availability 
Delivering results at delayed or batched intervals 
Integrating with SABA Interconnect 
65 In an embodiment, the final system and method of the 
present invention may be capable of scaling to handle 
enterprise-wide document databases. An initial prototype 
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that may be delivered is capable of demonstrating the 
proof-of-concept without exhibiting the scalability of the 
final system. 

The IDK provides a flexible mechanism for describing 
and comparing a wide variety of resources. The actual data 
being compared may vary widely among applications, rang- 
ing from competencies and skills for gap analysis to docu- 
ment summaries and reviews for web content. Yet the actual 
operations involved in determining a match tend towards a 
small set, text and numeric comparisons and basic Boolean 
logic. Thus, the IDK needs to casts a broad variety of 
properties into a consistent format for purposes of compari- 
son. 

In an embodiment, the invention employs the Resource 
Description Format (RDF), the World Wide Web Consor- 
tium's standard for web metadata. It meets the above 
requirements because it is designed to support a wide range 
of different applications, expressing them all in a consistent 
attribute property/value format. The format also allows the 
definition of standard vocabularies for specific application 
domains, and the mixing and matching of these vocabularies 
to describe a resource. The format has a web-centric design, 
employing URLs to describe any form of web resource and 
XML to serialize its data graphs and is seeing slow but 
steady adoption in a variety of domains, from electronic 
documents and on-line learning to news stories and business 
cards. 

By choosing RDF as the Information Distributor's stan- 
dard metadata format, the invention makes it easy and 
efficient for customers to work with the system because they 
can turn to external sources for training and documentation, 
can use third party tools for defining their metadata, and are 
more likely to already have or be able to find developers 
familiar with RDF. Furthermore, as RDF is used for more 
domains, the Information Distributor can be applied to an 
ever-increasing amount of content. 

RDF is essentially a model for representing attribute/ 
value pairs as a directed labeled graph. It consists of 
statements that pair a web resource (anything identified by 
a URL) with a property and a value. At its core, IDK 
provides a flexible mechanism for comparing these attribute/ 
value pairs and taking action upon the comparison results. 

The Match Agent operates by comparing one RDF 
description to the full set of RDF descriptions in a specified 
database. Because of the variety and flexibility of RDF 
descriptions, additional instructions are required to specify 
how the match is performed. This is the function of the 
match template. 

Match templates specify certain fields as belonging to a 
target RDF file. In an embodiment, the target is a file that is 
provided along with the match template to customize the 
search, for example, to perform a predefined search against 
a specific individual's description. Match templates may 
also be written to perform a fixed search, in which case there 
is no target RDF file. Merging a match template with a target 
RDF file produces an RDF query. 

Match templates can specify the following aspects of a 
query: 

The specific properties to be compared. 
The comparison operation (=, !=, <,>) 
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Boolean operators (AND, OR, NOT) 
A set of comparison functions, including: 

like (text matching) 

latest (most recent date) 
container operation: contains, first, etc. 
In an embodiment, match templates are: 

easy to create and edit by hand 

conducive to creation by an authoring tool 

easy to parse 

In an embodiment, the complete syntax and specification 
used by match templates is defined by the RDF Query 
Language Specification, described below. 

RDF-based Match Templates are unique and never before 
is contemplated by the prior art. The combination of a match 
template and a target RDF file can produce an RDF Query. 
In an embodiment of the invention, the core of the Infor- 
mation Distributor is a RDF Query- engine that performs a 
query on one or more RDF databases, then returns a set of 
20 resources that satisfy the query. 

In an embodiment of the invention, a client may use the 
Information Distributor SDK by performing the following 
exemplary method steps: 

1. Write an Import Agent that implements the 
25 ImportAgent interface and employs the MR. 

importRDF( ) method. 

2. Write a Match Agent that implements the Matchagent 
interface and employs the MR. match( ) method. 

3Q 3. Write a Delivery Agent that implements the Delivery- 
Agent interface. 

4. Create a new instance of an MR (Metadata Repository). 

5. Write code to create specific instances of the above 
agents and set them into motion. 

35 In an embodiment of the invention, an ImportAgent is 
responsible for delivering metadata in RDF format to a 
Metadata Repository. Specific Import Agents may interface 
with a particular source of metadata, translate that metadata 
into RDF, and use the MR.importRDF( ) method to import 

^ that RDF. Import Agents may register with the Event Man- 
ager to perform imports in response to particular events. In 
an embodiment, the ImportAgent has the sole responsibility 
for performing the metadata translation. In an embodiment 
of the invention, the invention provides utility routines that 
assist with translating various common metadata formats or 

45 serve to automatically generate metadata. In an embodiment, 
the invention provides additional utility functions for inter- 
facing with the Event Manager or scheduling batch imports. 

In an embodiment of the invention, a MatchAgent is 
responsible for performing a metadata match. Specific 

50 Match Agents may create a Match Descriptor and pass it to 
a specific MR to perform a match. Match Agents may 
perform matches in response to particular events. In an 
embodiment of the invention, distributed queries may be 
performed across multiple MR. 

55 Match Agents may employ a utility class called Match- 
Descriptor that captures all information needed for a meta- 
data query or match template. 
This class is defined as follows: 



public class MatchDcscriptor 
{ 

/** MatchDcscriptor constructor. 

* @param aTemplate Contents of a match template. 

* ©param aTargct URI of a target RDF file. May be NULL if the 
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match 

• template describes a fixed search. 

* @param aHandler MatchHandler to operate on the match results. 
•/ 

public Match Descriptor (String alemplate, String aTarget, 
MatchHandler aHandler) 

}/" MatchDcscriptOT */ 



Id an embodiment of the invention, a Delivery Agent is 
responsible for delivering the result of a metadata match. 
Delivery Agents implement the following Java interface: 



15 
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public interface Delivery Agent 

r* Deliver the results of a match. 

* @param mrs A MatchResultSet containing the match 

results. 

• ©exception Delivery Exception Thrown when 
delivery fails. 

V 

public void deliver (MatchResultSet mrs) throws 
Delivery Exception; 

} /* DeliveryAgeot 7 



Delivery Agents use a utility class called MatchResultSet 
that contains the result of a metadata match. A MatchResult- 
Set contains a Vector of RDFResource objects, a class 
containing a URI for each resource returned by a metadata 30 
match, as well as additional, optional properties. The 
MatchResultSet class is defined as follows: 



public class MatchResultSet 
{ 

/•* 

* Set the results. 

* @param thcRcsults Vector of RDFDescription objects. 
V 

public void setResults( Vector theResults) 
/" 

* Return an Enumeration of match results. 

* ©return Enumeration of RDFDescription objects 
V 

public Enumeration getResults( ) 



* </Description> 

* </resultset> 
+ 

In an embodiment of the invention, a MR (Metadata 
Repository) is an interface that any Metadata Repository 
must implement. " * " 

The following is the interface for a MR: 



public interface MR 
{ 

/* The import methods are used to insert RDF 
metadata into the MR. •/ 

/** Import an RDF document specified in a URL 

* @param uri URI to the RDF file. 

* ©exception ImportException Thrown when import 

fails. 

*/ 

public void importRDF (String uri) throws 
ImportException; 

/** Import an RDF document specified in a Reader. 

* The "key "parameter serves as a unique 

identifier; 

* when RDF is re-imported with the same key value, 
it replaces the previous 

* import The "key"value is most typically the 

URI. 

* @param r Reader containing RDF text 

* @param key Unique identifier for this RDF 



source, 
fails. 



In an embodiment of the invention, the contents of the 
MatchResultSet may be serialized as a simple XML docu- 
ment. One RDF Description element may be associated with 
each result. Using RDF permits the invention to deliver 
additional properties that may be useful to the consumer of 
the MatchResultSet, such as properties taken from the 
source RDF Description or additional properties returned by 
the Match Engine. 

The following is pseudocode for a sample XML result: 



50 
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* <resultset> 

* description about="http://sabainet/devo/starus/sbll_ 
12_99.htmr> 

* <dc:Title>Weekly Status of Project Sweet Baboo</ 60 
dc:Title> 

* </Description> 

* description about="http://sabainet/devo/status/Ipll_ 
08 99.htmr> 



* ©exception ImportException Thrown when import 



65 



<dc:Title>Weekly Status of Project Beethoven</ 
dc:Htlc> 



public void importRDF(Reader r, String key) throws 
ImportException; 

/** Perform a metadata match. This involves the 
following steps: 

* <ol> 

* <li> Extracting the contents of the 
Mate hDescrip tor 

* <li>GcncratLng a MatchResultSet 

* <li>Passing the MatchResultSet to the 
MatchHandler contained 

* in the Match Descriptor 

* </ol> 

* ©param md MatchDescriptor fully describing the 
match to perform. 

* ©exception MatchExccption Thrown when match 

fails. 

*/ 

public abstract void match(MatchDescriptor md) 
throws MatchExccption; 
/" 

* Retrieve a named property of a specific 
resource. Returns null if 

* the specified property docs not exist. 

* ©param resource URI of resource. 

* ©param namespace URI of namespace; null if no 
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A Property/Value/Operation triple can also contain a 

-continued nested Condition; this allows querying against reified 

statements, or statements about statements. Refer to Query 

namespace is specified. u fof ^ examp i e . 

• @param property Property name. . . Q „ r 

* ©return Property value. 5 ' ' , . , 

«■/ The Boolean operators perform logical operations on one 

public string getProperty(string resource, string or more conditions. Not negates the value of a single 

namespace, String property) throws MatchException; conditions, while And and Or perform logical operations on 

} /* MR */ two or more conditions. 

1Q Because many RQL operations operate on containers, 

there is an "applies" attribute that determines the behavior of 

In an embodiment of the invention, RDF Query Language grouping operators on containers. When "applies-within" 

(RQL) is an easy-to-learn, easy-to-author language for que- (the default), operations within a grouping condition must 

rying collections of RDF documents. It is designed to apply to me same value wimin a container. For example, this 

support the full functionality required by Information Dis- allows specifying conditions on two elements within the 

tributor. 15 same container element. When "applies^ across" conditions 

RQL is an XML application. An RQL document may need not apply to the same value in the container, 

consist of a single Select element containing a single Con- Notice that the Not operator returns all resources that do 

dition. A condition may be either a direct operation on a not satisfy the specified condition, which is not the same as 

single property, or a Boolean grouping operation, which can resources that satisfy the negation of the condition. Refer.to 

in turn contain further Conditions. RQL can define a number 20 Q uery 3 f or ^ example of this distinction, 

of built-in comparison operations; it also allows compari- Property 

sons against variables extracted from an accompanying ^ p^^y element identifies a specifiCj named prop _ 

target RDb tile erty of a Resource. Its contents identify the named property 

RDFQuery * " < ako lnmm 35 me P^te). Its contents can be a nested 

RDFQuery is the root element of an RQL document It * f**"* P ro P crt y separated by 

must contain a single Select element. forward slashcs * ^ svntax ma y navi g atc ovcr multiple 

Container properties, where each property value is a resource with its 

A container is a grouping property value. Containers can own Properties. This may be the same syntax used by RDF 

be Bags, unordered lists of resources or literals, Sequences, Query's "path" attribute for nested queries, 

ordered lists of resources of literals, or Alternatives, distinct M a convenience, it may not be necessary to specify 

choices. Container-related properties as part of the path, that is, Bag, 

Literal Seq, Alt, and li elements are automatically navigated past. 

A literal is a property value that is a simple string Value 

(including possibly XML markup) or other primitive The Value element defines the value against which a 

datatype. 3S specific property is compared. It can contain a literal string, 

Property which is compared directly against literal properties, or 

A property is a specific characteristic or attribute used to against a container property using one of the container 

describe a resource. The RDF model may contain operations. 

Statements, which are a named property and value assigned \ Q a Match Template, the Value element may also contain 

to a specific resource. 40 a Variable element, which indicates that the value is 

Resource extracted from the target RDF file. The Value element can 

Aresource may be ; anything .described by an RDF expres- also spcdfy a dt:dtype altribute lhat the datatype of 

sion. A resource is identified by a URL ^ value ^ Qo[y dataty p e that must be explicilly specified 

zf ?f , , j _ . is "dateTime," which indicates that a date comparison is to 

The^lectelement defines m « P^i^s that are returned 45 be performed on a IS0 8601 date. Date values can also 

by an RDF Query. The result of an RDF Query is itself an incorporate the "'sysdate" keyword to indicate an operation 

RDF document; it is the set of RDF Description elements based on me date Rcfer to Q 12 for an c le 

that satisfy the query. By default, only the Resource URI is Operation 

returned (as an about, aboutEach, or aboutEachPrefix ^ operation element defines how the comparison is 
attnbute of the Description element). The properties 50 per f ormed . rql supports a number of predefined opera- 
attribute is used to define additional properties to be ^ ons 

returned. It is a space-separated list of all property names to LUeral operations operate on values . include: 

be returned. The initial implementation only allows literal, , x „ nn t . , , ^ 

c 4 , . ^ . / , _ . . . . ' equals (=) performs an exact text match or numeric 

first-level property values to be returned; that is, containers, T . t .„ a . . o „™™ ttdt 

. r _f. ' , ' comparison. It will also match a resource URI. 

nested properties, and resources are not supported. 55 4 „ , , % x . A r 

Within the Information Distributor, the returned RDF ootEquals (!-) tests for mequahty. 

elements are wrapped in a MatchResultSet object for con- greaterThan (>) performs the numeric comparison, 

venient manipulation from Java. lessThan (<) performs the numeric comparison. 

Condition greaterThanOrEquals (>=) performs the numeric com- 

The Condition element defines a condition that RDF 60 parison. 

Descriptions must satisfy to be returned. Conditions are lessTh anOrEqu a Is (<=) performs the numeric compari- 

either simple, in which case they specify a Property/Value/ son. 

Operation triple, or complex, in which case they contain one like performs a substring text match, 

of the boolean operators. The simple Conditions simply We provide verbose forms of the various arithmetic 

obtain a property and compare it to the value using the 65 operations for readability; this is because characters such as 

specified operation. Operations are defined for literal prop- < require escaping within XML, which can become 

erties and container properties. unwieldy. 
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Document Type Definition (DTD) for RQL Documents 

<I- An RQL document contains a single Select element. --> 

<! ELEMENT rdf query (sclect> 

<!- Each Select clause contains a single Condition. 

The "properties'* attribute defines the information to 
return as part of the result seL 

Note that the URI of each matching Resource is always 
returned. -> 

<! ELEMENT select (oondition)> 

<!ATTUST select properties NMTOKENS #IMPLIED> 

<t— A Condition can either directly contain an operation, 
or contain s boolean grouping operator — > 

<! ELEMENT condition ( (operation+., property, value, 
condition?) | and j or | not)> 

<!— Boolean grouping operators — > 

<! ELEMENT and (condition, condition*) > 

<I— the "applies" attribute determines whether or not the 
condition within a grouping operation must 

all apply to the same value in a Collection. — > 

<!ATTLIST and applies (within | across) **within"> 

<! ELEMENT or (condition, condition*) > 

<!ATTLIST or applies (within | across) "within"> 

<! ELEMENT not (condition) > 

<!— An operation defines how to compare a property to a 
value --> 

<! ELEMENT operation (#PCDATA) > 
<!— Property identifies a specific property in an RDF file. 
For container objects, any children are acceptable 
matches, and intervening Container and Description tags are 
automatically navigated past --> 

<! ELEMENT property (#PCDATA> 

<!- A value defines the value to which a property is 
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Container operations operate on container values (Bags, 
Sequences, and Alternatives). They include: 
contains 
first 
last 

index(n) 
sum 
count 

Notice that the first, last, and indexo operations are only 
meaningfil for Sequences. 

Multiple Operations can be specified in a single Condi- 
tion; this is useful for queries that combine container and 
literal operations, such as a numeric comparison on the first 
entry of a Sequence. There are also two implicit shortcuts: 

1. A literal operation on a container first performs an 
implicit "contains/* 

2. A container operation without a further literal operation 
always performs an implicit "equals." 

Variable 

Hie Variable element defines a substitution variable. It 
contains a Property element, and is used to obtain a literal 
value from a target RDF file. 

Variable elements are only found in Match Template. 

Namespaces 

RQL supports namespace declarations as attributes of any 
element. It men applies these namespaces to property values. 
This means that property values can use namespaces pre- 
fixes. See the examples section for several illustrations of 30 
this technique. Notice also that this is an uncommon use of 
namespaces; rather than applying namespace declarations to 
element and attribute names, it is applied to the text within 
the document. 

Notice also that for variables, the corresponding 35 
namespace declarations must exist in the target RDF file, as 
opposed to the RQL file itself. 
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Document Type Definition (DTD) for RQL Documents 

compared. It is either a constant String, or a 

Variable whose value comes from a target RDF file. 
— > 

<! ELEMENT value (#PCDATA | variable)* > 
<!-- The value element can have a dt:type attribute 

specifying its datatype — > 

<!ATTLIST value dt:type NMTOKEN #IMPLIED> 

<!-- A variable indicates a property value obtained from a 

target RDF file; it contains a Property element — > 

< I ELEMENT variable (property)> 



The following are exemplary embodiments of RQL docu- 
ments. The example queries may; all use the following 
source RDF document: 
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<7xml vereion-"1.0"7> 

<rdf:RDF xmlns:rdf-"http://vvr^.w3.org/1999/TO/22-rdf-syiiU«- 

nsr 

xmlns:hr="http://www.saba.com/hr#" 
xmlns xwp- B http ://www.saba.com/ewp#" 
xmlns »ms="http yAvww.saba.eom/ems#" 
xmlns :vCard» " http^/imc.org^Card73.0#'> 
<rdf:Description 
about="http:/Avww.saba.conVpeople/sally_brown"> 
<vCard:N rdf iparseType= "Resource" > 
<vCard:Family>Brown</vCard:Faniily> 
<vCard:Given>Sally<ACard:Given> 
</vCard:N> 

<vCard:Un>>987-65-4320-^ACard:UID> 
<vCard:ROLE>Manager^Card:ROLE> 
<v Card: ORG rdf:parseType=" Resource" > 

<vCard:Orgname>Development</vcard:Orgname> 
</vCard:ORCr> 

<Jir:Location>HQ</hr:Location> 
<hr:Reports> 
<rd£Bag> 
-erdfcli 

resource-"http ://www.saba.com/peopte/Snoopy "/> 
<rd£li 

resource="http ://www.saba.com/people/Woodstock"/> 
<^rdf:Bag> 
<yhr:Reports> 
<ewp xompetency > 
<rd£Bag> 

<ra£ li>Java.Expert<tfrdf :li> 
<ra£Ii>XML.Proficient</rdf:li> 
</rdf:Bag> 
</cwp :compctency> 
<ewp:Interests> 
<rd£Bag> 

<rdf : li>Java<7rdf :li> 
<ra£li>EJB</rdf:li> 
<raf:li>COM</rdfdi> 
<7rdf:Bag> 
</ewp:lnterests> 
<ems:Training_Locations> 
<rd£Seq> 

<rd£li>San Francisco, CA</rdf Ji> 
<rd£li>San Jose, CA</rdf:li> 
<rdf:li>Los Angelca, CA</rdf:li> 
<rdf:li>Dcnver, CO</rdf:li> 
<yrdf:Seq> 
</ems :Training__Locations> 
</rdf:Description> 
<rdf:Description 

about-" http:/www.saba.com/people/sally_brown" bagID-"ID001 "> 
<ewp:compctcncy>EJBAdvanced<Vewp;competcncy> 
<^rd£Description> 

<rdf: Description aboutEach-"#ID001"> 
<c wp :attained>1999-02-25 </ewp:attained> 
<ewp:provider 
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rdf:resource="http^/www.sabanct/AllAbouJava/7> 
<ewp:details> 
<rdf:Bag> 
<rdf:li>CBT</rd£li> 
<odf:li>evalxiation<^rdf:li> 
</rdf:Bag> 
<v'cwp:dctails> 
<7rdf:Description> 
<frd£iRDF> 



The following exemplary query ("Query 1") associated 
with the above source RDF document selects all managers 
in a department: 
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<rdfquery> 

cselect properties=**vCard:FNAME vCardrORG" 
xmlns ^Card-"http^/imc.oig^vCard/3.0#" 
xmlns:hr= M http:/Avww.sabacom/lir#"> 
<condition> 
<not> 

<condition> 

<operation>equals</operation> 
<propcrty>brJ J ocation</property> 
<value>HQ</valuc> 
<condition> 
</not> 
<^condition> 
</select> 
<tfrdfquery> 



<?xml versio n-" 1 -0"?> 
<!DOCTYPE rdfiiucry SYSTEM "rqLdtd"> 
<rdfqucry> 
<select> 
ccondition 

xmInsrvCard»*'http:/Ainc.orgACard/3.0#''> 
<operation>equals</opeiation> 
<qjropcrty>vCard:ROLE</ptopcrty> 
<value>Manager<ftraIue> 
<fcondilion> 
</sclcct> 
</rdfquery> 



The following exemplary query ("Query 2")selects all 
developers in a department, or everyone in a development 
organization: 



The following exemplary query ("Query 5") finds an 
employee named "Sally Brown": 
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<7xml vereion=**1.0"7> 
<!DOCTYPE rdf query SYSTEM "rql.dtd"> 
<rdfiquery> 
<select> 
^condition 

xmla5.-vCard="http ^/imc.org^vCard/3.0# n > 
<operation>cqualsc/operation> 
<property>vChrd:ORG/vCaid:ORGNAME</property> 
<value> Development <yvalue> 
</condition> 
</select> 
</rdfquery> 



<7xml version-" 1.0"?> 
<!DOCTYPE rdfquery SYSTEM - rql.dtd"> 
<rdfquery> 

<select xmlns:vCard="http://imc.orgACard/3.0#''; 
<condition> 
<and applies="within"> 
<xondition> 

<op e rat ion >equa Is </ope ration> 
<property>vCarf^A<^nl:Fajnny</property> 
<va]ue>Brown</value> 
<condition> 
<condition> 

<op e rat ion >equa Is </ope ration> 
<propeTty>vCard^AOrd:Given<^property> 
<vahic>Sally <yvalue> 
</condition> 
</and> 
<condition> 
</se[ect> 
</rdfquery> 



40 The following exemplary query ("Query 6") selects 
everyone with a competency of "Advanced" in EJB: 



35 
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The following exemplary query ("Query 3") selects the 
name and division of everyone who is not located at a 
headquarter location: 



<?nnl vcr5ion=-1.0"?> 

<!DOCTYPE rdfquery SYSTEM "rql.dtd"> 

<rdfquery> 

<selcct pTopcrtics-"vCard:FNAME vCard.ORG" 
xmlns nX^ard=»**http:/Arrc.org/vOird/3.C)#" 
xmlns :hr- M http://www.saba.com/hr#"> 
<condition> 

<operatIon>notEquals</operation> 
<property>hr:Location</pTOperty> 
<valuc>HQ<vValuc> 
</condilion> 
<tfselect> 
</rdfquery> 



<7xml version-"1.0"7> 
<!DOCTYPE rdfquery SYSTEM "rql.dtd"> 
<rdfquery> 
<select> 

<condition xmln3:ewp-"http:/Avww.saba.oom/ewp#' f > 
<opeiation>contains</operation> 
<property>ewp:Competency</property> 
50 <value>EJB.Advanced</value> 
</condition> 
</se!ect> 
</rdfquery> 



The following exemplary query ("Query 7") selects 
everyone who will train in San Francisco: 



60 



The following exemplary query ("Query 4") returns slightiy 
different results, in that it also returns all resources that do 
not have an hr Location property: 



65 



<?xml verskm-"1.0"?> 
<!DOCTYPE rdfquery SYSTEM "rql.dtd"> 
<rdfquery> 
<select> 

<condition xmln5:erns= M http://www.5aba,com/ems#''> 

<opera tion>conta ins </ope ratio a> 

<property>ems:Training_Locations Vproperty> 

<vaIue>San Francisco, CA<tfvalue> 
</condition> 
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-continued 



</select> 
</rdfquery> 



The following exemplary query ("Query 8") selects 
everyone will train in some location in California and return 
to that location: 
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<?xml vcraion="1.0"?> 
<!DOCTYPE rdf query SYSTEM "rqLdt£T> 
<rdfquery> 

csclect propcrtics="cm3 :Training_Locatioii5" 
xmlns :ems°"http yAvww.sabaxom/cms#"> 
<condition> 
<opcraUon>likc</opcration> 
<propcrtp^ms:Trauiiiig_JLocatioDS</propcrty> 
<value>CA</value> 
</condition> 
<fselect> 
</rdfquejy> 

The following exemplary query ("Query 9") selects 
everyone whose first choice of training location is anywhere 
in California; 



<property>hr :Report8</property > 
<value>2</value> 
</condition> 
</select 
</rdfquery> 



The following exemplary query ("Query 12") finds all 
who have an advanced competency rating in EJB, with the 
competency ratings obtained from evaluations. 



13 <?xml version&"1.0"?> 

<IDOCTYPE rdf query SYSTEM "rql.dtd"> 
<rdfquery> 

■ • <sclcct xmlns:cwpx«"http7/www.saba.coin/cwp#''> 

<condition> 

<operation>cquaJs</operation> 
20 <propcrty>ewp:compctcncy</propcrty> 
<value>EIB.Advanccd </value> 
<condition> 

<opcration>contaiii5</opcration > 
<property>ewp:details</property> 
<value>evaluation</value> 
</condition> 
</condition> 
</select> 
</rdfquery> 



cTxml vcrsion="1.0"?> 

<!DOCTYPE rdfquery SYSTEM "rqLdtd"> 

<rdfquery> 

<sclcct propcrtics=»"cim :Training_Loca lions" 
xmlns :ems=~http VAvww.saba.eom/ems#"> 
<condition> 

coperatioa>iodcx (1) </opcraticn> 
<operatioD>lilce</opcraLion> 
<property>ems:Traiiiing_JjOcations-</propeTty> 
cvaluc >CA</valuc> 
</condition> 
</selcct> 
</rdfqucry> 



30 The following exemplary query ("Query 13*') finds every- 
one hired in the past month: 
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The following exemplary query ("Query 10") finds the 
manager of an employee named "Woodstock": 



<?xml version-"!. 0'7> 

<!DOCTYPE rdfquery SYSTEM "http://dlipkin/rqLdtd"> 
<idfqucry> 

<select xmlns: hr«"http:/Avww.saba. co m/hr#" 
xmlns :dt-"urn :w3-org3mldatatypes"> 
«ondition> 

■coperation>greaterThan</operatioii> 
<property>hr StartDate</property> 
<vaiuc dt:typc= < *dateTimc , '*>sysdatc-31<^valuc> 
</condition> 
</select> 
</rdfqucry> 



<7xml vereton="1.0"7> 
<!DOCTYPE rdfquery SYSTEM "rqLdfcTV 
<rdfqucry> 
<select> 

<condition xmlra:hr-"hUpy/www.saba.comyhr#''> 
<opcration>contains</opcration> 50 
<qpror*rty>hr:Repoits</property> 
<vahie>http ^/www.saba.coin^ople/W6od5tock<A r aiue> 
<fcondition> 
</select> 
</rdfquery> 



The following exemplary query ("Query IV s ) finds all 
who have more than two direct reports: 



<?xml version=**1.0*?> 
<!DOCTYPE rdfquery SYSTEM "rql.dtd"> 
<rd£qucry> 
<select> 

<condition xmlns: hr-"http y/www.saba.cam/hr#"> 

<opcration>couatVopcration> 65 
<operation>greatxrThan</opexation> 



Information Distributor Implementation 

The following is an exemplary implementation embodi- 
ment of Info Distributor in the platform of the invention. The 
implementation has two components: 

1. DatabaseMR — a Java class that implements a Metadata 
Repository (MR) on top of a relational database. This 
class provides utility methods to be invoked by Import 
Agents, Match Agents, and Delivery Agents. 

2. RQL parser — a Java class that implements the RQL 
query language. It parses an RQL document and 
executes the query using the DatabaseMR. 

In an embodiment, DatabaseMR implements the MR 
interface, that is, it provides the ability to import an RDF 
document, return the value of an RDF property, and perform 
a metadata match. 

DatabaseMR uses a database schema containing the fol- 
lowing tables: 

MR_sources — contains URI references to each imported 
document 
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Column 


Datatype 


Description 


id 

source_TJRI 


number 

varchar2(1024) 


Primary key 

URI of imported document 


MR_jriples_base — stores the actual data of all RDF 
triples from imported RDF documents. 


Column 


Datatype 


Description 


rd£_propcrty • 

rdf_resource 

rd£_object 


number 

. varchai2(1024) . 
varchar2(1024) 
varchar2(1024) 


Foreign key to MR_sources 
table 

• - Property values ~ -~ . 
Resource values 
Object values 
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In addition, there is a view called MR_triples defined as 

CREATE VIEW MR_triples AS (SELECT rdf_property, 

rdL_resource, rdL_object FROM MIL_triples base) 2S 
This view allows other data sources to also be manipu- 
lated by the MR, as described below. 
As an example, the following RDF document: 

30 

<?xml vereion="l.(T?> 

<rd£RDF xmlns :rdf-"http ://www.w3.orgA 999/0 2/22-rdf-6yntax- 

ns#" 

imlns :dc-"http ^ypurl.org/dc/elements/3 . 1/" 
xirdns:schcduJe="http:/Avww.xaba.conVRDF/schedu]e/1.0ir> 35 
<rdf: Description rcsourcc«"http^/dlip]dn/classl"> 
<dc:title>HTML Fundamentals</dc:title> 
<schedule :startDate>l 998-1 2-07</gchedule:startDate> 
</rdfJ)escription> 
</rdf:RDP> 

40 

appears as the following data: 



private void generatTYiples (Reader r, String key) throws 
ImportException 
{ 

r » (Reader) new RDPReader(r); 
InputSource source ° new [nputSource (r); 
source. setSystemId(key); 

RDFConsumer consumer = (RDFConsumcr) new 
DatabaseMRCo nsumer(this); 

mSirpac.se tRDFSource(source); 

mSirp ac.se tStrcamModc(mUSE_STREAMING_PARSER); 
mSirpac. register(consumer^ 
mSirpac. fetch RDF( ), 



where DatabaseMRConsumer is a callback class invoked 
by SiRPAC that simply invokes the insertTripIe( ) 
method of DatabaseMR: " ~ 



private class DatabaseMRConsumer implements RDFConsumer { 
private DatabaseMR mNR; 

public DatabaseMRConsumer (DatabaseMR theMR) 
{ 

mMR =» theMR; 

} 

public void start (DataSouroe ds) { } 

public void end (DataSouroe ds) { } 

public void assert (Data Source ds, Resource predicate, 
Resource subject, RDFnode object) { 

mMR.in3ertTriplc(predicate.toString( ), 
subject. tostring( ), object. toString( )); 

} 

}; 



4. Insert each triple into the MR_triples_base table using 
a prepared statement of the form: 

INSERT INTO MR_triples_base(id, uri_ref, rdt_ 
property, rdf_jresource, rdfL_object) VALUES(MR_ 
sequence.nextval, ?, ?, ?, ?) 

5. Commit the transaction. 
match( ) 



rdf__resource rdf_property rdfL_object 

http^/dlipkin/class 1 http://purl.0rg/dc/cIc1nents/l.lAitlc HTML 

Fundamentals 

httpy/dlipkin/class 1 http://www.sahm.eom/RDF/schedule/l.0#startDatc 1998-12-07 



The methods of DatabaseMR are implemented as follows: 
importRDF( ) 55 
The importRDF( ) method imports RDF data. It uses 
W3C*s open-source RDF parser, SiRPAC (hup:// 
www.w3.org/RDF/Implementations/SiRPAC/) to generate 
triples from an RDF document. 6Q 
This algorithm followed by this method is: 

1. See if this document has already been imported. If so, 
delete all triples resulting from the previous import. 

2. Insert the key for this document into M R_sources. 6S 

3. Invoke SiRPAC to parse the document and generate 
triples, using Java code similar to the following: 



The match( ) method takes a MatchDescriptor specifying 
a Match Agent and Delivery Agent and performs a match. It 
uses the following algorithm: 

1. Extract the RDF query and target RDF document from 
the MatchDescriptor. 

2. Parse the query using RQLParser. 

3. Execute the query by invoking the getResources( ) 
method on the root Operator returned by RQLParser. 

; . Pass in the target RDF document as an argument, and 
obtain a result Vector of matching resource Strings. 

4. Construct a MatchResultSet of the query results. 

5. Dispatch the query results to the Delivery Agent. 
getPropcrty( ) 
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The getProperty( ) method returns the value for a specific 
property stored in the MR. It does this by invoking a SQL 
statement of the form: 

SELECT rdf_object FROM MR_triples WHERE rdt_ 
resource-? AND rdf property ? 

Database Schema 

The database schema used has two main advantages: 

1. Simplicity. All RDF data is stored in a single table and 
all SQL is written to read and write to this table. 

2. Support for non-RDF data. It is simple to cast non-RDF 
data into this format so that existing or legacy data can 
be queried by the DatabaseMR using RQL. 

So, for example, for the following example data stored in 
an "invoices" table: 



id 


last updated 


customer 


1 


30-JAN-99 


Foid 


2 


25-FEB-99 


Cisco 



The view used by the MR can be augmented as followed 
to incorporate this data: 



create view invoioc_date_triplcs as 
select 1 lasL_updated' "idf_praperty", 

('invoiced 1 1 id) "rdf_resource", 
to_char(last_updated, ' YYYY-MM- DD') M rd£_objecr 
from test^in voices; 
create view invoice_customer_ triples as 
select 'customer* "rdf_property", 
(* invoiced 1 1 id) "rd£_resource*\ 
customer "rdf_object" 
from test_invoices; 
drop view MR_triples; 
create view MR_triples as 

(select rdf_propcrty, idf_jcsource, rdf_object from 
invoice_date_triples) 
union 

(select rdf_property, rdf_resource, rdfL_object from 
invoice_custo me r_ triples) 
union 

(select rdf__property, rdf_re source, rdf__object from 
MR_triples_basc); 



Tliis will result in the following additional triples being 
available from the MR: 



rdf__re source rd£_property rdf_object 

invoiced last„updated 10-JAN-99 

invoiced customer Ford 

invoiced last_updated 25-FEB-99 

invoice#2 customer Cisco 



The disadvantage to this schema is that it is not normal- 
ized and stores a tremendous amount of duplicate data. 
Many values for rdf_resource and rdfjroperty will be 
duplicated, since the same resource will have a number of 
properties, and property names will come from a well- 
known set. 

RQLParser 

RQLParser parses an RQL document and builds an execu- 
tion plan for the query. The plan consists of a tree of Java 
classes called "Operators," where each Operator is respon- 
sible for returning a Vector of matching resources. 
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The Operator interface is defined as follows: 



public interface Operator 

{ 

* An operator knows how to return a Vfector of matching 
resource values 

* (typically URIs). 

* @param conn JDBC connection to the MR 

* (Sparam target RDF Target RDF file. 

* ©return Vector of matching resources 

* ©exception SQLException Thrown on a database error 
V 

public Vector getResources (Connection conn, String 
targetRDF) throws SQLException, ParseException; 
} /* Operator */ 



A variety of Operators are provided, each of which is 
. responsible for . handling, different RDF constructs or RQL-. 
operations. Some of the available Operators are: 
20 AndOperator — implements the "and" boolean operator. It 
contains an array of child Operators. It calls getResources( ) 
on each one, then constructs a result Vector of the resource 
that are present in each and every child. 

OrOperator — implements the "or" boolean operator. It 
25 contains an array of child Operators. It calls getResources( ) 
on each one, then constructs a result Vector of the resource 
that are present in any child. 

SimpleOperator — an abstract class that contains a prop- 
erty string, a value string, and a child Operator. It is the 
30 superclass for both SingleOperator and ContainerOperator. 
SingleOperator— a SimpleOperator that handles basic 
expressions, ie equals or notEquals. It executes a SQL query 
of the form: 

SELECT DISTINCT rdf_resource FROM (SELECT * 
35 FROM MR_triples WHERE rdf_property-?) 
WHERE rdf_object [operation]? 

The value for [operation] is provided by the concrete 
subclass. Available subclasses include: 

EqualsOperator 
40 NotEqualsOperator 

GreaterHianOperator 

LessThanOperator 

LikeOperator 

45 The value used to match the rdLjobject can either be 
provided as hard-coded text in the RQL document, or it can 
be defined as a variable containing a propertyName. In this 
case, a metadata match is performed, using the target RDF 
document as the source for the property value. 

5Q ContainerOperator — a SimpleOperator that operates on 
an RDF container (a Bag, Seq, or Alt). It contains a child 
operator that it executes to return a set of generated 
resources representing the RDF container. It then executes a 
SQL query of the form: 

55 SELECT rdf_resource FROM MR_triples WHERE 
rdf_property=? AND rdf__objecto? 
where each rdf_object is set to one of the child resources. 
Additionally, there is an OperatorRegistry class where 
each Operator is registered with the RQL operation it 

60 supports. 

RQLParser uses the following algorithm and methods for 
generating the execution plan: 
1. parse( ): 

Parse the RQL document using a standard XML parser to 
65 obtain the resulting DOM tree. 

Navigate to the main condition node and call 
parseCondition( ) on it. 
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2. parsecondition( ): 

If the condition is a boolean, call parseBoolean( ). 
Otherwise, call parseOperation( ). 

3. parseBoolean( ): 

Obtaining each child node and recusively calling 
parseCondition( ) on each one. 

Create the appropriate Operator for the boolean 
(AndOperator, OrOperator, NotOperator) with the children 
obtained by calling parseCondition( ). 10 

4. parseOperation( ): 

Obtain the operation, property, and value nodes. 
Extract the text values of these nodes, and call 
crcateOperator( ) with these values. 

5. createOperator( ): 

a. Use the OperatorRegistry to obtain the Java class of 
" the "Operator responsible for this operation. * 

b. Use Java reflection to create a new instance of this 
Operator class, passing in the appropriate param- 20 
eters. 

Agents 

Agents are implemented as clients of the DatabaseMR 
class. 

For example, a simple ImportAgent will pass its text RDF 25 
argument to the importRDF( ) method: 
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public class SimplelmpartAgent implements ImportAgent 
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{ 



private MR mMR - null; 
public SimplcImportAgent (MR theMR) 

{ 

mMR - theMR; 

{ 35 

public void unportRDF(String rdf) throws ImportException 

Reader r - (Reader) new StringReader(rdf); 
/* this import has a unique key so it can never be 
overridden by 

subsequent imports */ 

String key = "generated" + System.currenrnmeMillis( ); 
mMR.unportRDF(r, key); 
} /* importRDF •/ 
} /* SimplelmportAgent */ 



A simple MatchAgent will take an RQL document and a 45 
DeliveryAgent as parameters, and invoke the match( ) 
method: 
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public class SimpleMatchAgent implements MatchAgent 

private MR mMR » null; 
private DeliveryAgent mDA - null; 
private MatchDescriptor mMD = null; 
public SimpleMatchAgent (MR theMR, String rql, 
DeliveryAgent theDA) 
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{ 



theDA); 

} 



mMR » theMR; 
mDA - theDA; 

mMD ■» new MatchDescriptor(rql, " " (MatchHandler) 
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public void match( ) throws MatchException 

mMR.match(mMD); 
} /* match */ 
} /* SimpleMatchAgent •/ 
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A simple DeliveryAgent prints the RDF document con- 
taining the matching resources to System .out: 



public class Simple DeliveryAgent implements MatchHandler 

public void deliver(MatchResultSet mrs) throws 
Delivery Exception 

String xml m mrs.toXMLO; 
System .outprint(xml); 

} /* SimpleDeliveryAgent •/ 



Best Mode 

As indicated earlier in FIG. 3, the architecture of a 
preferred embodiment of the present invention adopts a 
three-tier model. Referring now to FIG. 17, the various types 
of computer hardware 'and co'mpuusf sofhvare *us^ 'm a 
preferred embodiment at the present time are depicted in 
greater detail. In FIG. 17, a tier 1 user workstation 1701 and 
a tier 1 dedicated user personal computer (PC) 1703 are 
connected electronically to a tier 2 web server 1707 via the 
Internet 1709. FIG. 17 also shows a tier 1 user smart phone 
1705 directly connected to a tier 2 application server 1711, 
such as the SABA Business Platform. And the tier 2 appli- 
cations server 1711 may be connected to a tier 3 database 
management system 1713, additional external SABA sys- 
tems 1715, external third party systems 1717 and/or third 
party knowledge management systems 1719. 

The user workstation 1701 can be a Sun® Ultra5™ 
workstation and the user PC 1703 can be any general 
purpose PC. Note that the list of tier 1 devices presented in 
this preferred embodiment are not conclusive. Other tier 1 
user devices could be WebTV or other Personal Assistant 
Devices (PDAs). A Sun E250™ dual processor server can be 
used as a development/test system running the Sun® 
Solaris® operating environment, Oracle® 81. A single pro- 
cessor Sun E250™ server can be used for the SABA 
Business Platform, as a Sun E4500™ dual processor, an 
IBM NetFinity 7000™ quad processor with a Microsoft® 
NT™ server and a Hitachi Shared Disk array. The worksta- 
tion 1701 and the PC 1703 can interface to the tier 2 SABA 
Business Platform through the Internet 1709 using a stan- 
dard Internet browser such as Internet Explorer™. The tier 
3 database can be located on an Oracle 81® server, a SQL 
server, or Informix. The Sun E250™ dual processor server 
can interface with the external third party systems 1717 via 
third party system specific adapter plugs. The Sun E250™ 
dual processor server also interfaces with external SABA 
systems 1715 via SABA exchange. Finally, the Sun E250™ 
dual processor server can also interface with the tier 3 
database management system 1713 located on the Oracle 
81® server. 

Referring again to FIG. 17, the tier 2 applications server 
1711 is expanded to illustrate the SABA Business Platform 
(Platform) of the present invention. In FIG. 17, the Platform 
contains an Interface Server 1721, an Information Server 
1723, an Interconnect Server 1725, and a Business Server 
1727. In a preferred embodiment, all of these Servers 1721, 
1723, 1725, and 1727 may physically reside on the same 
hardware platform (such as a UNIX box or a Microsoft™ 
NT™ platform), or each server may reside on a separate 
hardware box, or any combination of servers and hardware 
boxes. Each of the servers has included a JAVA Virtual • 
Machine™ and the related runtime support. 

In a preferred embodiment, the business server 1727 
embodies the containers which incorporate all of the busi- 
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ness logic, common business objects, SABA core objects, 
and a database driven framework for generating notifications 
and for triggering periodic events based on context sensitive 
attachments. The business server 1727 communicates with 
each of the other servers within the Platform using the XML 5 
protocol (1727, 1729, and 1731). The Business Server 1727 
also communicates with the database management system 
1713. In communicating with the interface server 1721, the 
business server 1727 first generates a XML message 1729 
and transmits it to the interface server 1721. The interface 10 
server 1721 then performs style sheet transformations on the 
XML using XSLor XSLT to translate the XML message into 
the particular Applications Programming Interface (API) 
language required to communicate with a particular user. 
For example, if a particular user is accessing the Platform 15 
via a workstation 1701 or a PC 1703, the Interface Server 
1721 can convert the XML 1729 into HTML 1735 and 
communicate with the user through' a web server 1707 via 
the Internet 1709. The Interface Server 1721 can also 
convert the XML into other protocols such as WAP/WML 20 
1737 to communicate with Personal Data Assistants (PDAs) 
such as cell phones 1705, Palm Pilots™, or other such 
wireless devices. Since the interface that is generated 
between the Platform and the various user interfaces is 
dictated by the set of style sheets generated in the Interface 25 
Server 1721, the same core business logic can be leveraged 
to communicate across a number of different user interfaces. 

The Interconnect server 1725 uses XML to communicate 
with both the Information server 1723 and the Business 
server 1727 and is responsible for all connectivity external 30 
to the Platform. Externally, the Interface Server 1721 may 
communicate with third party systems such as SAP™ 
accounting or personnel packages, Oracle™ financial or 
human resources, other SABA Platforms 1715, and gener- 
ally any external system to which a portion of the Intercoo- 35 
nect facilities may be connected. The Interconnect server 
1725 comprises SABA interconnect 1739 which is essen- 
tially a backplane into which cards or interconnect services 
can be plugged. Examples of these cards or interconnect 
services can be an event monitor 1741, exchange registry, 40 
node manager 1747, connectors, accessor 1743, or subscrib- 
ers 1745. Each of these cards or interconnect services 
leverage the services provided by the SABA interconnect 
backplane 1739 for communicating between the cards them- 
selves and for providing more sophisticated services to third 45 
party systems 1717. 

Apreferred embodiment of the Platform may interconnect 
with a third party system 1717 having, for example, an 
Oracle human resources (HR) database 1749 and an Oracle 
financial database 1751. Tne third party system 1717 has a 50 
third party interconnect backplane 1753 with similar cards 
or interconnect services. The third party interconnect back- 
plane 1753 connects to the third party databases 1749 and 
1751 via system specific adapters 1755. These system spe- 
cific adapters 1755 differentiate between different types of 55 
databases such Oracle, SAP, or PeopleSoft and feed into the 
standardized Platform framework so information can be 
exchanged. An example of information that can be 
exchanged includes HR information. When a new employee 
is added to or terminated from the third party HR system 60 
database 1749, the monitor 1757 located on the third party 
interconnect backplane 1753 notifies the subscriber 1745 
located on the SABA interconnect backplane 1739 via XML 
1759. The accessor 1743 on the SABA interconnect back- 
plane 1739 can then access the new employee data via XML. 65 
The Interconnect server 1725 then performs style sheet 
transformations to convert the XML into the Platform's 
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native format and transmits that data to the Business server 
1727 which then updates the database management system 
1713. This data connection can be set to be automatic or with 
modifications. 

In a preferred embodiment, the Interconnect server 1725 
also embodies a workflow and notification scheme. For 
example, if a group of students signed up for a class through 
the Platform and later the class time changes, the Platform 
can detect this change and initiate a workflow to obtain all 
the names of the students from the database management 
system 1713 and send an email to them notifying them of the 
change. Thus, the interconnect server 1725 can provide 
real-time, in-order, reliable updating of data, financial 
transactions, or management of human capital between the 
Platform and third party systems 1717. 

The Interconnect server 1725 can also be used to syn- 
chronize the Platform with other external SABA systems 
1715. For example, the Platform can publish a catalog and 
based on permissions that are set, the catalog can be sub- 
scribed to by some other external SABA systems 1715. 
Whenever changes are made to the catalog, the external 
SABA systems 1715 can monitor that change and obtain an 
update immediately. The Interconnect server 1725 can also 
connect to SABA private learning networks which are 
connected to SABA public learning networks via SABA 
Exchange. For example, a third party such as Ford Auto- 
motive may have a SABA system allowing them to 
exchange catalog or class course information via the inter- 
connect server 1725. 

The Information Server 1723, communicates with the 
Interconnect server 1725 and the Business Server 1727 via 
XML. The Information Server 1723 also communicates 
directly with the database management system 1713 for 
query and storage of metadata 1733. The Information server 
1723 focuses on queries and distributed queries and keeping 
track of information about other pieces within the Platform. 
Hie Information Server 1723 can also leverage the Inter- 
connect server 1725 to connect to a third party knowledge 
management system 1719 that generates information via the 
SABA Interconnect backplane 1739. For example, a third 
party may have a third party Interconnect backplane 1761 
connected to a Knowledge Management System 1719 which 
monitors and exchanges data with the Platform via XML. 
The Information Server 1723 contains Import, Match and 
Delivery agents to resolve and generate information 
requests; Match templates to match metadata; and template- 
based services that respond to information requests and are 
capable of rendering their results in XML; and Finders — 
metadata driven, template-based query builders that gener- 
ate optimized SQL queries in the native SQL language of the 
particular database involved. 

Having described the invention in terms of a preferred 
embodiment, it will be recognized by those skilled in the art 
that various types of general purpose computer hardware 
may be substituted for the configuration described above to 
achieve an equivalent result. Similarly, it will be appreciated 
that arithmetic logic circuits are configured to perform each 
required means in the claims for performing the various 
features of the rules engine and flow management. It will be 
apparent to those skilled in the art that modifications and 
variations of the preferred embodiment are possible, such as 
different computer systems may be used, different commu- 
nications media such as wireless communications, as well as 
different types of software may be used to perform equiva- 
lent functions, all of which fall within the true spirit and 
scope of the invention as measured by the following claims. 
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What is claimed is: 

1. A method for managing data exchange between sys- 
tems connected via a network, comprising: 

creating a plurality of predefined stylesheets, each said 
stylesheet of said plurality of stylesheets describing a 5 
mapping between a system specific local format and a 
generic interchange format; wherein the generic inter- 
change format is independent of a specific platform or 
system; 

receiving a data object from a first system in a first system io 
specific local format; translating said data object from 
a first system specific local format to a generic inter- 
change format object with a first predefined stylesheet 
using a system specific service component which uti- 
lizes a native application programming interface of said 15 
first system; 

translating said data object from said generic interchange 
format- to a second system specific local format-object 
with a second predefined stylesheet using a system 
specific service component which utilizes a native 2Q 
application programming interface of said second sys- 
tem; and 

transferring said second system specific local format 
object to said second system. 

2. The method of claim 1, wherein said step of receiving 

a data object from a first system in a first system specific 25 
local format comprises: 

receiving a request to export a data object from a first 
system; 

identifying a local data object identifier utilizing a mapper 
component; 

identifying a document type utilizing a mapper compo- 
nent; 

identifying a stylesheet and transformer mechanism using 

said document type; and 
extracting said data object from said first system. 

3. The method of claim 2, further comprising converting 
said local data object identifier to a platform object identifier. 

4. The method of claim 1, wherein said step of translating 
said data object from said generic interchange format to a 
second system specific local format object with said second 40 
predefined stylesheet using a system specific service com- 
ponent which utilizes a native application programming 
interface of said second system comprises: 

receiving a request to import a data object to a second 
system; 45 

receiving a data object in a generic interchange format, a 
document type, and a platform object identifier; 

identifying a stylesheet and transformer mechanism using 
said document type; and 

translating said data object from said generic interchange 
format to a second system specific local format object 
with said stylesheet using a system specific service 
component which utilizes a native application pro- 
gramming interface of said second system. 

5. The method of claim 4, further comprising: 55 
scanning for foreign platform object identifiers; and 
resolving said foreign platform object identifiers to a local 

identifier. 

6. The method of claim 1, further comprising returning a 
local identifier for said data object transferred to said second 60 
system. 

7. The method of claim 1, further comprising the step: 
monitoring a first system for changes to a data object at 

said first system 

8. The method of claim 1, wherein said step of receiving 65 
a data object from a first system in a first system specific 
local format comprises extracting said data object from said 
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first system with a system specific service component which 
utilizes a native programming interface of said first system. 

9. The method of claim 1, wherein said step of transfer- 
ring said second system specific local format object may be 
performed using a plurality of communication protocols. 

10. The method of claim 1, wherein said first predefined 
stylesheet is an xsl stylesheet. 

11. The method of claim 1, wherein said data objects are 
in xml format. 

12. The method of claim 1, wherein said step of translat- 
ing said data object from a first system specific local format 
to a generic interchange format object with said first pre- 
defined stylesheet using a system specific service component 
which utilizes a native application programming interface of 
said first system comprises: 

translating said data object into a serialized local XML 

representation; and 
translating said serialized local XML representatipnjQ ,a . , 

generic interchange format utilizing a predefined 

stylesheet. 

13. The method of claim 1, wherein said step of translat- 
ing said data object from said generic interchange format to 
a second system specific local format object with said 
second predefined stylesheet using a system specific service 
component which utilizes a native application programming 
interface of said second system comprises: 

mapping said data object in generic interchange format to 

one or more objects required to be transferred to said 

second system; and 
translating said generic interchange format data into said 

second system specific local format using a predefined 

stylesheet. 

14. An apparatus for managing data exchange between 
systems connected via a network, comprising: 

a network interface; 

memory storing data and programs of instructions; 
a processor coupled to the memory which executes the 
programs of instructions and accesses the stored data, 
wherein the programs of instructions comprise: 
a first translator component for translating a data object 
from a first system specific local format to a generic 
interchange format object, wherein said generic 
interchange format object is both platform and sys- 
tem independent, said first translator component 
comprising: 

a system independent service subcomponent; and 
a system specific service component utilizing a 
native API of said second system to translate said 
data object from a generic interchange format 
object to a second system specific local format 
object using a second predefined stylesheet; and 
a second translator component for translating said 
data object from said generic interchange format 
to a second system specific local format object, 
said second translator component comprising: 
a system independent service subcomponent; and 
a system specific service component utilizing a 
native API of said second system to translate said 
data object from a generic interchange format 
object to a second system specific local format 
object using a second predefined stylesheet; and 
a delivery component for transferring said data 
object between said first and second system. 

15. The apparatus of claim 14, wherein said programs of 
instructions further comprise: 

a monitor component for monitoring changes of a data 
object at a first system, said monitor component com- 
prising: 
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a system independent service subcomponent; and 
a system specific service component utilizing a native 

API of said first system to monitor changes of said 

data object at said first system. 

16. The apparatus of claim 14, wherein said programs of 
instructions further comprise a mapper component for iden- 
tifying a local object identifier and a document type. 

17. The apparatus of claim 14, wherein said first pre- 
defined stylesheet is an xsl stylesheet. 

18. The apparatus of claim 14, wherein said data objects 
are in xml format. 

19. A method for managing data exchange between sys- 
tems connected via a network, comprising: 

creating a plurality of predefined stylesheets, each said 
stylesheet of said plurality of stylesheets describing a 
mapping between a system specific local format and a 
generic interchange format; 

- • receiving a data object from a first system in a first system 
specific local format; 

translating said data object from a first system specific 
local format to a generic interchange format object with 
said predefined stylesheets using a system specific 
service component which utilizes a native application 
programming interface of said first system; 

translating said data object from said generic interchange 
format to a second system specific local format object 
with said predefined stylesheets using a system specific 
service component which utilizes a native application 
programming interface of said second system compris- 
ing; 

receiving a request to import a data object to a second 
system; 

receiving a data object in a generic interchange format, 
a document type, and a platform object identifier; 

scanning for foreign platform object identifiers; 

resolving said foreign platform object identifiers to a 
local identifier; 

identifying a stylesheet and transformer using said 
document type; and 

translating said data object from said generic inter- 
change format to a second system specific local 
format object with said stylesheet using a system 
specific service component which utilizes a native 
application programming interface of said second 
system; and 

transferring said second system specific local format 
object to said second system. 

20. The method of claim 19, further comprising returning 
a local identifier for said data object transferred to said 
second system. 

21. The method of claim 19, further comprising the step: 
monitoring a first system for changes to a data object at 

said first system. 

22. The method of claim 19, wherein said step of receiv- 
ing a data object from a first system in a first system specific 
local format comprises extracting said data object from said 
first system with a system specific service component which 
utilizes a native programming interface of said first system. 

23. The method of claim 19, wherein said step of trans- 
ferring said translated data object may be performed using a 
plurality of communication protocols. 

24. The method of claim 19, wherein said stylesheet is an 
xsl stylesheet. 

25. The method of claim 19, wherein said data objects are 
in xml format. 

26. The method of claim 19, wherein said step of trans- 
lating said data object from a first system specific local 
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format to a generic interchange format object with said 
predefined stylesheets using a system specific service com- 
ponent which utilizes a native application programming 
interface of said first system comprises: 
5 translating said data object into a serialized local XML 
representation; and 
translating said serialized local XML representation to a 
generic interchange format utilizing a predefined 
stylesheet 

10 27. The method of claim 19, wherein said step of trans- 
lating said data object from said generic interchange format 
to a second system specific local format object with said 
predefined stylesheets using a system specific service com- 
ponent which utilizes a native application programming 
15 interface of said second system comprises: 

mapping said data object in generic interchange format to 

-.one or. more objects. required to be .transferred to said 

second system; and 
20 translating said generic interchange format data into said 
second system specific local format using a predefined 
stylesheet. 

28. An apparatus for managing data exchange between 
systems connected via a network, comprising: 

25 a network interface; 

memory storing data and programs of instructions; 
a processor coupled to the memory which executes the 
programs of instructions and accesses the stored data, 
wherein the programs of instructions comprise: 
30 a monitor component for monitoring changes of a data 
object at a first system, 
said monitor component comprising: 

a system independent service subcomponent; and 
a system specific service component utilizing a 
35 native API of said first system to monitor changes 

of said data object at said first system; 
a first translator component for translating a data object 
from a first system specific local format to a generic 
interchange format object, said first translator com- 
40 ponent comprising: 

a system independent service subcomponent; and 
a system specific service component utilizing a 
native API of said first system to translate said 
data object to a generic interchange format object 
45 using a predefined stylesheet; 

a second translator component for translating said data 
object from said generic interchange format to a 
second system specific local format object, said 
second translator component comprising: 
50 a system independent service subcomponent; and 

a system specific service component utilizing a 
native API of said second system to translate said 
data object from a generic interchange format 
object to a second system specific local format 
55 object using a predefined stylesheet; and 

a delivery component for transferring said data object 
between said first and second system. 

29. The apparatus of claim 28, wherein said programs of 
instructions further comprise a mapper component for iden- 

60 tifying a local object identifier and a document type. 

30. The apparatus of claim 28, wherein said predefined 
stylesheet is an xsl stylesheet. 

31. The apparatus of claim 28, wherein said data objects 
are in xml format. 

* * * * * 
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